Different deployment environments!

Posted on by

Many organizations these days are utilizing numerous deployment environments, which their DevOps groups use to approve the necessary features prior to moving the particular builds to production. Instead, each developer should utilize different deployment environments to build and release their sprints prior to delivering potentially shippable items.

It doesn’t make any difference which development methodology you are using for your project i.e either Agile or Waterfall etc, yet you should follow this practice to have separate deployment environments to:

  • Avoid Risks and errors in the application
  • Keep Code Quality High
  • Easier detection of error
  • Deliver quality builds

Which Deployment Environments are we referring to here?

Deployment environments are the place where DevOps groups build, test, and deploy their application and test if everything works in according to the expectations with no bugs or outages in isolated environments, prior to moving to production/live environment.

Essentially all environments need to be production-like environments having similar infrastructure and configuration.

Though it relies upon project to project requirements, however, generally the following environments can be used:

1) Development Environment

  • Let’s take an example of a developer having the most recent code version on his local machine or local development environment. So developer creates the build of the code, test, and deploys it to the remote development environment.
  • Development environment has the recent version of code and developers check if their code is working on the development environment according to the expectations (with similar infrastructure as of production environment).
  • Once the developer finishes his testing on the development environment, the latest code gets pushed to the next – staging environment.

2) Staging Environment

  • Staging is like a pre-production environment or a clone of the production environment, with similar infrastructure and configuration as of the production environment.
  • When the latest code is updated on a staging environment, the team can perform Integration and load testing on the staging environment.
  • This is the environment, where one can discover issues related to functional bugs, UI/UX issues, application security, and performance issues before moving to production.
  • Once the QA finishes a last round of testing on the staging environment and the project incharge gives the final go-ahead, then the latest changes/build got deployed to the production environment.

3) Production Environment

  • Production is the LIVE environment, where the application is running for the live customers.
  • After the latest deployment, QA does smoke testing on the production environment to detect bugs in real-time scenarios and guarantees that the application is stable and works as per expectations.

* Additional Tips

  • You can use CI/CD pipelines for Continuous Building, Testing, and Deploying code changes to various environments using tools like Jenkins, AWS CodeBuild, etc.
  • For the disaster recovery, you should have the production server backup or snapshot of your production volume so in case required, you should have the option to restore that instance.