This document discusses continuous delivery and outlines its main benefits and steps. Continuous delivery aims to create a predictable, high-quality release process through automation and feedback loops. The key steps include building, quality checks, automated testing, provisioning environments, and production deployment. This allows for low-risk releases, faster delivery of value, and quality improvements. Automating testing is important but some manual testing like smoke testing and user acceptance testing remains necessary. Tools can help set up continuous delivery pipelines to deploy applications through various stages like acceptance testing, capacity testing, and blue/green deployment to production.
3. codecentric Nederland BV
≒Experience with Continuous Delivery?
≒As a tester, do you need to wait for an
acceptable release from developers?
≒Loose time doing all repetitive manual stuff?
≒Maintain different environments and software versions manually,
over-and-over-and-over
≒Is this really release 1.6.5?
≒All sounds familiar?
TYPICAL
11. codecentric Nederland BV
WHAT IS CONTINUOUS DELIVERY
≒ Continuous Delivery pipeline
≒ Automation
≒ Manual control
≒ Feedback
12. codecentric Nederland BV
WHAT ARE THE MAIN STEPS OF CONTINUOUS DELIVERY?
≒ Build compile, unit test, version, package
≒ Quality metrics, documentation
≒ Test acceptance-, regression- and performance tests
≒ Provision environments deployment to test- and staging
environment
≒ Production green/blue deployment to production
13. codecentric Nederland BV
WHAT ARE THE KEY BENEFITS OF CONTINUOUS DELIVERY?
≒ Low-risk releases
≒ Faster return on investment in software projects
≒ Improvement of competitiveness and responsiveness
≒ Quality improvement of new software versions
14. codecentric Nederland BV
ANATOMY IN DETAIL
Source
Code
Commit Stage
Compile
Commit Tests
Assemble
Code Analysis
Artifact Repository
Acceptance Stage
Configure Environment
Deploy Binaries
Smoke Test
Acceptance Tests
UAT
Configure Environment
Deploy Binaries
Smoke Test
Capacity Stage
Configure Environment
Deploy Binaries
Smoke Test
Run Capacity Tests
Production
Configure Environment
Deploy Binaries
Smoke Test
Env.&App
Config
Env.&App
Config
Version Control
Testers
Self-service
deployments
Operations
Perform push
Button releases
Developers
See code metrics
and test failures
reports
binaries
metadata binaries
reports
metadata binaries
reports
metadata
15. codecentric Nederland BV
MAIN STEPS TO CREATE A CONTINUOUS DELIVERY PIPELINE?
≒ Getting started with virtual environments, e.g. Amazon EC2
≒ Configure your Continuous Integration Server
≒ Provisioning your Test, Staging and Production environments
≒ Configure your Continuous Delivery Pipeline
≒ Create a Dashboard of your Systems
20. codecentric Nederland BV
OUR SETUP
https://github.com/...
CD Server
Test Server
User Acceptance
Test Server
Production Cluster
Blue / Green
CD Slave
21. codecentric Nederland BV
EXAMPLE DELIVERY PIPELINE 1/2
Push to Git Repo
1
Provision-Deploy
Acceptance
Commit
Trigger CD Pipeline
2
Build Source Code
3
Run Unit Tests
4
Start EC2 Image
1
Provisioning
2
DB Create Update
3
Deploy WAR
4
Start Tomcat
5
Start Selenium
1
Acceptance Test
Run AATs
2
Version Git Repo
6
Release WAR
7
Run Code Analyse
5
22. codecentric Nederland BV
EXAMPLE DELIVERY PIPELINE 2/2
Run JMeter
1
Provision-Deploy
UAT
Start EC2 Image
2
Provisioning
3
DB Create Update
4
Deploy WAR
5
Start Tomcat
6
Performance
Test
Select Version
1
Provision-Deploy
PRODBLUE/GREEN
Start EC2 Image
2
Provisioning
3
DB Update
4
Deploy WAR
5
Start Tomcat
6
Select Version
1
26. codecentric Nederland BV
ANATOMY OF A DEPLOYMENT PIPELINE
Release
≒ Every change results in a trigger of the deployment process
≒ Software is build once and only once
≒ The same deployment process for every environment
≒ Deployment in production-like environments
Commit
Automated
Acceptance Test
Automated
Capacity Test
Manual
Testing
Fast Feedback
Trust in Application Stability
Done
28. codecentric Nederland BV
SUMMARY
≒ Continuous delivery is a way to create a stable release process
≒ Manual testing is (still) necessary
≒ Pull vs Push
≒ Dashboard