Part 1 — Deployment Environments
On this page 7 headings
What is an environment?
Section point: An environment is a system, or a set of systems, that executes a software application.
Developers write and test code, and an environment builds that code into something that runs and that users or other people can access. A software team usually works with four kinds of environment:
- Development environment
- Testing environment
- Staging environment
- Production environment
Not every team has all four, but development, testing and production are almost always present. Staging is very common and strongly recommended. The code moves through the environments in this order:
Development → Testing → Staging → Production
1.1 Development environment
The development environment is the local environment of an individual software developer: their own machine, with an IDE and whatever other tools they like to use.
In this environment the developer:
- writes code,
- tests it (unit tests),
- builds the code base to check that it compiles and works, and
- commits the code to the shared code base kept in a version control system (such as Git).
Two terms from the example diagrams are important:
- Working copy: the developer’s own copy of the code base on their machine.
- Mainline / master branch: the shared code base in version control that everybody commits to.
Before or while committing, the developer must check that their working copy does not clash (conflict) with changes other developers have already made to the mainline. Any conflicts must be resolved.
The development environment is also connected to a local database. The developer can freely read from and write to it without affecting the real data of the live system.
1.2 Testing environment
When developers have written and unit-tested their code, the code in the shared repository is placed in the testing environment. Here, integration testing and system testing are carried out: the pieces written by different people are tested together, and then the system is tested as a whole.
If a test fails, the lecture describes this procedure:
- The defective code is removed from the testing environment.
- The module in which the failure occurred is identified.
- The developer responsible for that module is identified and notified.
- The code in the testing environment is rolled back to the previous working version.
- The responsible developer fixes the bug in their own working copy and commits it to the shared code base again.
- The fixed code reaches the testing environment in the next scheduled deployment.
1.3 Staging environment
Once the code has been tested thoroughly, can it go straight to users? Usually it first goes to a staging environment.
Section point: Staging is a pre-production environment; it exactly resembles the production environment in hardware, software and configuration, and runs on a remote machine.
Reflection: why not push directly to production?
Think about this before reading on. The lecture gives three reasons for having a staging environment.
- Deployment is complicated and risky. Deploying involves many activities and configurations: installing libraries and packages, configuring them, running scripts (for example, initialising the database). The same is true when updating modules or adding features to a live application. If this is done directly in production and something goes wrong, the live system can crash and affect real users. Doing it first in staging, an exact replica, shows whether the installation and updates work. Successful rehearsal reduces release risk; it does not guarantee a safe production release.
- Previewing new features. Staging is a good place to show new features to management, the sales or marketing team, or a client, without releasing them to everyone.
- Performance and stress testing cannot be done locally or in the testing environment. Doing it in production would affect users, so staging is used.
1.4 Production environment
The production environment, also called the live environment, is where the software actually runs for all its users. Users interact with it directly, and it holds real data.
What happens when a new feature is requested?
Suppose the application is live and working, and the client asks for a new feature (a new user interface, say). The team goes through one more iteration of the life cycle: design, then development. Each developer modifies the code in their working copy, tests it and commits it to the shared code base, and the change passes through testing → staging → production again.
The last step, moving the new version from staging into production, needs care, because production is the system people are using right now. The move must be smooth. The planned way of doing it is called a deployment strategy.