Target Deployment Servers/Environments

In our last article of Software Release and Deployment, we discussed in detail about target deployment servers or environments.

I hope you have got an idea about them through our last article, but just to throw more light on deployment environments, I chose to write this article.

So, lets start with basics of Target Deployment Servers/Environments.

Deployment environments are those environments where the build gets deployed and programs are executed.

It could be a selection of individual servers, configured clusters and middle ware that collaborate to provide an environment to host software modules which would be available to the end users.

If there is a small project team, then its pretty common that developer are developing the program and immediately executing it on the same machine, that means having only single environment.

Whereas, when we look at the industry standards there are different environments which are meant to be used separately according to their role.

Let’s discuss about these different types of environments.

Developer’s Local environment: Its developer’s own machine where developer write the code for the assigned small module.

Once the developer finishes the work, developer checks-in the changes into the source repository which will create a build if the build tool is configured for repository trigger.

Dev/Test environments: These environments are simply a development server or a test server on which the build gets deployed which is being built from the source code which was developed and committed by the individual developer.

These environments are rapidly updated and contains the most recent version of the application.

Integration environment:   This environment acts as a common environment where builds having all developers commits is deployed.

The purpose of this environment is to combine and validate the work of the entire project team so that the whole project work can be tested and feed back in case of any issue before sending out the build to the Staging environment.

It is pretty common that small scale industries use Dev environment as an Integration environment by following the fact that  developers will cooperate with each other and not deploying the build from their machine which was built from their local copy of the source code.

QA environment: The Quality Assurance Environment is an optional environment in case you need a dedicated testing environment to run all sort of tests once the build is passed in Integration testing environment.

The QA environment is solely used for testing. This helps to test in two versions of software, one on Integration environment and other on QA environment.

Some people refers QA environment as Staging environment but it depends.

Staging environment: The staging environment is also known as pre-prod environment. It is a environment that is as identical to the production environment as possible.

It may connect to other production services, protocols, data, such as databases, etc or might have a same replica of production data.

This is just to make sure that the code which is going live is not breaking anywhere and functioning properly as expected.

This environment is also used for performance testing, particularly load and stress testing, as this offers a replica of prod environment.

Production environment: Here comes the main environment, this environment is also know as Live environment.

It could be a single server for smaller industries but in all other industries its a clustered environment which consist many machines.

Once the build is passed from all the above mentioned environments it can be deployed on Prod environment but not in similar way how it was being deployed everywhere. It has to follow defined protocols and according to the release plan.

There are several approaches for deploying the build and configuration on Prod environments as these are the most important and sensitive environments.

There could be minimal or no downtime if swapping, etc is configured but its an organizational call how they want to configure their main system.

Otherwise, there would be some downtime as new release generally requires a restart, and most of the organizations propose the live deployment in out of office hours

There could be few more environments, such as DR environment (Disaster Recovery) which functioning similar to stage environment but with exact prod level server configuration in order to continue the service in case of any failure in live environment.

As time goes on, bug reports and feature requests are made and get assigned to the project team. Then it can go live by following any type of release which needs to be decided and approved by all the stack-holders.

This is all about the deployment environments from my side, its just an attempt to brief you about the basics of their terminology, you will get to know more about these environment once you start working on them.

I’ll continue talking about “Software Release and Deployment” with the best practices to follow in our next article.

Till then, stay tuned!