Continuous delivery
1 like447 views
This document discusses continuous delivery and provides steps to achieve it. Continuous delivery aims to provide fast, high quality feedback at multiple levels through the development process. It recommends having automated source control, builds, testing, deployment, monitoring and self-healing systems. The key steps are to have automated builds that pass all tests with each change, to measure and improve code quality, to implement automated validation of both code and features through tests, and to deploy and monitor applications automatically to catch any issues. Containers can help developers deploy applications for testing more easily. The overall goal is to establish a pipeline that allows for frequent, low-risk deployments.
Continuous delivery
- 1. Continuous Delivery A talk by Alex Bolboaca @alexboly
- 2. Can You Drive With Your Eyes Closed?
- 3. Can You Develop Without Feedback? Obama doing politics
- 4. Can You Develop Without Feedback? Obama learning to program
- 6. Why Continuous Delivery? Fast, High Quality feedback on more levels: 1. Is this feature useful? 2. Is this feature stable? 3. Can this feature be deployed? 4. Is the feature correct? 5. Is the code quality at good standards?
- 9. How to Get To Continuous Delivery?
- 10. Warning! Advice on this topic is very context dependent I will give you hints but you have to find your own way Instead of solutions, grasp the principles and philosophy
- 11. 0. Source Control ● Pick one: git, svn, TFS ... ● Define your: – Main branch (e.g. master) – Integration branch (e.g. login)
- 12. 0'. Integration Policy ● Many variations ● Example: – Feature branches and personal branches – Every day you merge the feature branch into your personal branch – When your story / task is done, you merge your personal branch into the feature branch – Every day someone merges the integration branch into the feature branch – Once the feature is done, it is merged in the integration branch
- 13. 1. Automated Build ● Can you build the system with one click? ● If not, start with a local script before moving to a build server
- 14. 1I. Measure Code Quality ● Can you find most common mistakes automatically? ● FxCop, JsLint, Sonar, Emma, … ● Start by ignoring all rules except the most important ● The build should fail if the metrics go down from previous version ● Publish evolution graphs on the server
- 15. 1II. Automated Validation (Code) ● Did you make a mistake? ● Unit tests ● Use the code coverage metric as a trend ● Focus your tests on the most common sources of bugs
- 16. 1V. Automated Validation (Feature) ● Is the feature working? ● Acceptance tests ● Selenium or similar tools
- 17. V. Automated Deployment ● Can you deploy with one click? ● Has more phases. Example: – Stop tomcat – Upload jar to deploy directory – Update tomcat configuration – Start tomcat – Figure out if tomcat started successfully – Figure out if app is working (smoke test)
- 18. V'. Containers! ● Admin configures container ● Dev takes container, deploys application on it ● Dev checks that the app works on the container ● Container gets deployed to server
- 19. VI. Monitoring ● Is the application working on long term? ● Monitoring: – Smoke test – Transform tests into monitoring features – Performance, Scalability, Security ...
- 20. VII. Self-Healing ● What do you do when the app fails? ● Use monitoring to self heal! – if hard drive is full, save logs to S3 – if out of memory, restart server or scale to next Amazon instance – If high traffic from limited number of IPs, block them (DoS response)
- 23. Any other questions? “The important thing is to never stop questioning”