Development Environments

I’ve been thinking for a while about trying to write this post, but was too lazy to do that. Now I think it’s time.

When you work on a project you need an environment to test what you are doing. Especially, if this is a big interprise system with complicated deployment process and many dependencies on other systems (usually a system could both depend and be dependent on other systems)

I’ve faced the problem of testing my projects several times. When you finish your task, but don’t know how to check that it works. Sometimes it’s not possible to run it on your local computer, and sometimes if it is, working system on your computer doesn’t mean that it’s going to work on production. So I want to share my thoughts how the process could be accomplished on my point of view. To be said that’s not my idea, I just want to share the experience that I think is good enough. So let’s get started.

In big enterprise systems there are usually many roles working on a project. Some of them are business analysts, system analysts, QA engineers, developers, deployment engineers. Based on that let’s say that there are different layers of environments for a particular role group.

Let’s assume that there are 2 projects depending on each other, project A and project B. Different teams work on each project. So how to do development and make sure all that work?

Here is how I think this could be accomplished. Again, this is not my idea, but I like it. You can have 3 layers of environments. Let’s call them DEV (development), QA (quality assurance) or SIT (system integration testing), UAT (user acceptance testing).

DEV environment is an environment where a developer can deploy and run the system to see how it’s working (or not working:) ) All dependencies to another systems can be stubbed on this layer. We don’t care if the dependent systems work on this stage. For project A and project B there could be different DEV environments, like DEVA and DEVB, so the projects could work and be deployed isolated from each other. QA team can also work on this environment to perform some testing. Once a QA team or a development team is happy with the results the project is deployed on the next layer – QA or SIT.

QA or SIT environment is an environment where QA team works on testing how the whole system works, including both project A an project B. On this stage there are no stubs. On this layer both project A and project B get tested. Once this is done, the whole system is deployed to the next layer – UAT.

UAT environment is an environment where end users perform testing. This is the stage where end users provide sign off for the system. This environment should look like as production as much as possible. After end users are happy with the system, the system can be deployed on production.

There is one more environment that stands out of the environments I described above. This is a prod like environment. On this environment anyone from dev or qa or a user can take a look how the system is currently working. This can be very useful when there is a bug and you don’t know if this was done in current release or it’s from production. Also, sometimes it is useful to see how the system works on production to figure out some behavior that you are not sure where it came from.

Thank you for reading!