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.

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

5. So, Feedback!

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?

7. The Pipeline
Source: http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment

8. The Sibling
Source: http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment

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)

21. The Pipeline
Source: http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment

22. Contact Me
Alexandru Bolboaca
alex.bolboaca@mozaicworks.com
@alexboly

23. Any other questions?
“The important thing is to never
stop questioning”