This document discusses implementing continuous delivery practices. Continuous delivery aims to have software always ready for deployment by automating the development process, including coding, testing, and deployment. The key aspects are establishing an automated deployment pipeline and practicing continuous integration, deployment, and delivery. The document outlines steps to transition from a manual process to continuous delivery, including upgrading processes and using a patch installer tool to automate upgrades. Metrics are also important to measure the effectiveness of continuous delivery practices.

1. Mauricio Ferreyra
09/18/2013
Implementing
Continuous Delivery

2. Topics
▪ What is continuous delivery?
▪ The deployment pipeline
▪ Continuous integration / deploy / delivery
▪ The current process
▪ Why continuous delivery
▪ How do we achieve continuous delivery?
▪ First steps
▪ Continuous upgrade
▪ Essential Practices
▪ Next steps
▪ Conclusion
▪ Questions & Answers
2
Footer 1

3. What Is Continuous Delivery?
3
Footer 1
• A set of practices to have software always ready to be
deployed to Production.
• Goal: Provide feedback about parts of development
process together
• coding, build, testing, deployment, data management,
environment management and release management.

4. The deployment Pipeline
4
Footer 1
• The deployment pipeline is an representation of the
implementation of your build-deploy-test-release process.
• Must be automated

5. Continuous Integration / Deploy / Delivery
5
Footer 1
Continuous
Integration
Continuous
Delivery
Continuous
Deployment
▪ Continuous integration is about code.
▪ Continuous deployment is about components
▪ Continuous delivery is about the bussines

6. The current process
6
Footer 1
Coding
Unit test
Build installers
User
Acceptance
test cases
DeploymentInstallation
• Continuos integration cover the commit stage.
• What about other stages?
• We are deploying manually
• Lots of manual configurations
• We are running the automated test cases manually
• We are deploying to a production like environment only when
development is complete

7. Why Continuous Delivery?
▪ We need increase the confidence all the time in the
product.
▪ Development time is uncertain time.
▪ We need feedback all the time.
▪ We need reduce the release risks
▪ We need reduce the stress
▪ We need reduce the deployment complexity
▪ Emergency fixes
▪ The release time must be a business decision, not technical
decision.
7
Footer 1

8. How Do We Achieve Continuos Delivery?
▪ Incrementally and collaboration
▪ Fixing the automation problems
▪ Fixing the installation problems
▪ Fixing the upgrading problems
▪ Finding out where the bottleneck is, and fix that.
8
Footer 1

9. First steps in Continuous delivery
▪ http://172.16.8.149:8080/view/Continuous_Deployment/
9
Footer 1

10. 10
Footer 1
Demo
Continuous Delivery

11. Continuous upgrade
▪ We need change our upgrade process from manual to
automated
▪ We need include it in the deployment pipeline
11
Footer 1

12. ▪ Upgrade contains:
- Binaries files: jar, ear, war, .sh
- SQL’s scripts
- Configurations
• New files
• Update entries
▪ We are performing the upgrades through a plain text file.
12
Footer 1
Continuous Upgrade (CU): What We are
doing?

13. CU: What We need start to do?
▪ Remove the upgrade plain text from all modules
▪ Create an automated process to perform all task
automatically
13
Footer 1

14. ▪ Patch installer supports all the task to install, upgrade and
extend the product.
▪ Capacity to install from a required version
▪ Task
- Deploy
- Copy
- Copy-plugin
- Upload-config
- Sql
- runScript
- Mkdir
14
Footer 1
CU: The Patch Installer Tool

15. 15
Footer 1
CU: Demo
The Patch Installer Tool

16. ▪ Automated (almost) everything
▪ Version Configuration
▪ One Build, one deploy
▪ Database changes is backward and forward compatible
with the applications
▪ Same deploy on every environment
▪ Features incrementally
▪ Toggles feature
16
Footer 1
Essential Practices

17. Essential Practices (cont.)
▪ Every build should be a release candidate
▪ Fail Fast and often
▪ Parallel Tests
▪ Test on Production like environment
▪ Zero downtime deployments
17
Footer 1

18. Next steps
▪ RQM integration
- The Sanity Suite, the full regression and all the user acceptance test
will be manage from RQM by the Release Management Team.
▪ Customer Pipelines
- The continuous delivery add value to the product
- We need implement a complete pipeline for each customer
▪ Implement Performance and Capacity
- Deploy periodically on our HA environment automatically
- Run the Performance and Capacity
▪ Metrics
- We need measure the effectiveness of CD
18
Footer 1

19. Next Steps ( Cont. )
▪ Metrics
- Feedback should be the heart of the continuous delivery process.
- Number of commits to the version control system per day
- Number of builds succesfull
- Number of build failures per day
- Duration of build, including automated tests
- Scalability of the testing
- Measure the stability of the environments
19
Footer 1

20. ▪ The purpose of continuous delivery involved everyone in
delivering of the product.
▪ Don’t Repeat Yourself: automated everything.
▪ The same deploy on all environments
▪ Done means released
▪ No human intervention during the deployment.
▪ Provide Fast and Useful Feedback
▪ Keep Merchandiser Releasable All The Time
▪ Make All Changes Incrementally
20
Footer 1
Conclusion

21. Questions & Answers
21
Footer 1

22. References
▪ Continuous delivery book
▪ Lean Software Development book
▪ www.continuousdelivery.com
22
Footer 1