CONTINUOUS INTEGRATION
CONTINUOUS DELIVERY
CONTINUOUS DEPLOYMENT
But first things first, let's define these terms:
continuous integration is a practice where developers merge their changes back to the master branch
as often as possible, running tests to validate the changes
continuous delivery means that, after CI validation, the deployment process to production is
automated and can be triggered simply clicking on a button
continuous deployment means that, after CI validation, the deployment to production is triggered
automatically
CIAO!
Antonello D'Ippolito
Software engineer, Scrum master
@antodippo
VONQ is a company that helps other companies to find the right talent for their job vacancies.
We have a platform that integrates different services for job marketing, guiding the recruiter with
recommendations for channels on which advertise it. They are
mainly written in PHP and Javascript, but also Python and Scala for the machine learning part.
I'll tell you how we are trying to build continuous stuff.
FAST AND TINY PRs
CODE REVIEWS
PAIR PROGRAMMING
FEATURE TOGGLES
Feature toggles (often called also feature flags) are the technique for adding a functionality in such
a way that it can be turned on or off, and it allows developers and product managers to:
- integrate code in master branch often, even if a feature is incomplete
- change the system behaviour without changing the code
- make A/B testing, experimenting feature, doing partial releases, but we'll get to that
if ($toggleManager->isActive('new_fancy_functionality')) {
$this->newFancyFunctionality();
} else {
$this->oldFunctionality();
}
https://www.martinfowler.com/articles/feature-toggles.html
- release toggles, which allow incomplete features to be integrated into the master branch, and turned on
only when completed or when product management decides to: "separating release from deployment". They
should have a short life and be changed in a more static way, at the deployment stage
- experiment toggles, with which you can place users in specific cohorts and show them a specific version
of a feature. They should have a short life and be changed in a dynamic way, probably on each request
- ops toggle, to control operational aspects of the system, for example to measure the performance of a
specific functionality before rolling it out to all users. They are usually short-lived, but there could
also be long-lived ops toggles to switch off heavy and not vital functionalities. They are often managed
as a runtime configuration
- permission toggles, to release a feature to a set of "premium" users. They are very dynamic, changing
for every request, and long-lived
DECOUPLE TOGGLE FROM DECISION
CENTRALIZE THE LOGIC
AVOID CONDITIONALS
REMOVE TOGGLES
ACTIVE
INACTIVE
CONDITIONALLY ACTIVE
“IF IT HURTS, DO IT MORE OFTEN”
MONITOR EVERYTHING
ERROR LOGS
CRONS EXIT STATUS
EXTERNAL SERVICES CALLS RESPONSE TIME
CONTROLLERS LOADING TIME
DECOUPLE DEPLOY FROM RELEASE
A/B TESTING
CANARY RELEASES
Yeah, ok, but... what's in it for me?
IT SHARPENS YOUR DEVOPS SKILLS
FAST FEEDBACK
FROM CI
FROM MONITORING
FROM USERS
YOU'RE GONNA FAIL. THE PROBLEM IS HOW SOON
“El camino es la recompensa”
Oscar W. Tabarez
“That’s why, even if you can’t actually release every set of changes that passes all your tests,
you should aim to create a process that would let you do so if you choose to.”
Continuous Delivery - Jez Humble, David Farley
- automating your entire build, deploy, test, and release process.
- comprehensive, reliable set of automated tests.
- writing system tests that run against a production-like environment.