One of the main accelerators of DevOps is within its deployment pipeline. Adjustments to an application must become available for production as early as possible to provide the desired flexibility of an development project, while maintaining the stability of operational aims. This can be done with an optimized and centric deployment pipleline, as the one illustrated below:
There are different kind of deployment pipelines, having different degrees of readiness:
- Continuous Integration
Automatic build and deployment into an integration environment. This includes an automatic schedule for integration tests. - Continuous Delivery
Contains Continous Integration. This pipeline contains automatic triggers as far as the staging system, where the User Acceptance Test (UAT) is also executed. - Continuous Deployment
Contains Continous Delivery. This pipeline includes the next step, e.g. deployment to production is automized as well. After deployment to production a deployable is supervised closely until it becomes promoted to normal production.
Deployment Stages
The configuration for certain environments must be done via configuration parameters within the application to reflect the required environment and correlating debug level.
Pre-Commit
This stage is done on local environments, e.g. the computer of developers. Therefore external systems are stubbed out or mocked. Having mock services is therefore a requirement for software engineering. Further only limited data and read-only external systems are used for testing.
Build and integration testing
This stage is done on an continous integration server (e.g. the counterpart for Jenkins). The code is compiled and the component is build and baked into a VM image or deployable which will not be changed afterwards. Testdata is used to form a test database for executing automated tests incl. integration; a connection to production data is strictly forbidden.
UAT / Staging / Performance testing
This environment is as close to production as possible. Multiple automated tests are run against the deployable:
- acceptance tests
- performance tests
- stress test
The data used for this stage is a subset of the production data and contains large data sets to test within a realistic setup.
Production
Production contains the live database and sufficient resources to adequately handle workloads. Productive systems may also have active tests running which is also called live testing. This can be realized via the concept of the Simian Army, which provide active (Chaos Monkey, Latency Monkey) and passive (unused resources, expired certificates, health checks) tests. Also canary options are possible for a go-live.