This document discusses CartoDB's use of continuous integration and deployment practices. It defines continuous integration, delivery, and deployment. CartoDB breaks its codebase into components and products. It aims to reduce risk through practices like feature flags, canary releases, quick rollbacks, post-mortems, and smoke tests. Continuous deployment provides benefits like early issue detection but requires plans for risks like database locks and integration issues. It is not suitable for all organizations.
36. Continuous
Integration
[CI.2] “Continuous Integration is a software
development practice where members of a
team integrate their work frequently,
usually each person integrates at least daily -
leading to multiple integrations per day.
Each integration is verified by an
automated build (including test) to detect
integration errors as quickly as possible.”
XP (1999), Booch method (1991)
37. Continuous
Delivery
[CD.1] “software engineering approach in
which teams keep producing valuable
software in short cycles and ensure that the
software can be reliably released at any
time.”
[CD.2] “You build software in such a way that
the software can be released to production
at any time”
38. Continuous
Deployment
[CD.1*] “software engineering approach in
which teams keep producing valuable
software in short cycles and ensure that the
software can be is reliably released at any
time.”
[CD.2*] “You build software in such a way that
the software can be is released to
production at any time”
40. [CI.1]
1. Maintain a code repository
2. Automate the build
3. Make the build self-testing
4. Everyone commits to the
baseline every day
5. Every commit (to baseline)
should be built
6. Keep the build fast
7. Test in a clone of the
production environment
8. Make it easy to get the latest
deliverables
9. Everyone can see the results of
the latest build
10. Automate deployment
Best
practices
42. [CI.1]
1. Maintain a code repository
2. Automate the build
3. Make the build self-testing
4. Everyone commits to the baseline
every day
5. Every commit (to baseline)
should be built
6. Keep the build fast
7. Test in a clone of the
production environment
8. Make it easy to get the latest
deliverables
9. Everyone can see the results of
the latest build
10. Automate deployment
Best
practices
51. Feature flags
[FF.1] “The basic idea is to have a
configuration file that defines a bunch of
toggles for various features you have
pending. The running application then uses
these toggles in order to decide whether or
not to show the new feature.” - Fowler
54. Canary
Releases
[CR.1] “Canary release is a technique to
reduce the risk of introducing a new
software version in production by slowly
rolling out the change to a small subset of
users before rolling it out to the entire
infrastructure and making it available to
everybody.”