Gabriel’s new feature went from their own computer, into the version control system, passed tests, and was merged into the source code. Now, it’s time to “deploy to production”! But what exactly does that mean?
The production environment refers to the infrastructure that supports the complete application used by real users. This infrastructure consisted of hardware and software components scaled for real-world usage.
More broadly, an environment is the subset of infrastructure resources used to execute a program under specific constraints.
Along the way to the production environment, software often moves through a series of intermediate environments. Each intermediate environment allows developers to rigorously test new software without impacting production infrastructure.
Though the names of environments may differ from company to company, a common set of environments includes:
- The local development environment — where software is first written and tested, typically on a developer’s own computer.
- The integration environment — where software changes are merged using a version control system.
- The quality assurance (QA) / testing environment — where tests are executed to ensure the functionality and usability of each new feature.
- The staging environment — where the software can be performance tested in a production-like environment, but before real users are involved.
- The production environment — where software is accessible by real users!
These environments do not strictly represent a linear path from a developer’s computer to production. Instead, each of these environments can be viewed as a space that developers can use throughout the entire deployment process.
In the image for this exercise, we can see three deployment environments: development, staging, and production. Once a new feature is created in the development environment, it is tested in intermediate environments, and finally released to users!
Using a staging environment is quite similar to using focus groups to test new products. It’s important for a company to test how a new feature will behave in real-world scenarios, without running the risk of releasing a potentially faulty product to all of its users.
Want to learn more? Check out our full article on environments.
The movement of software in and out of intermediate environments is a common source of bugs, particularly when these migrations are performed manually. In the next lesson and throughout this course, you will learn about how DevOps seeks to mitigate these issues through automation. Before we get there, continue to the final exercise to review what we have learned about deployment.