Continuous Delivery Presentation
Download as PPTX, PDF1 like353 views
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.
Continuous Delivery Presentation
- 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
- 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
- 22. References ▪ Continuous delivery book ▪ Lean Software Development book ▪ www.continuousdelivery.com 22 Footer 1
Editor's Notes
- #7: Continuous Integration is a big step to quality of code Provide Good metrics But is not enough. A green build dont provide the real status of the product