CI/CD and Automation

Fast feedback

Pair programming

…approval by an external body (such as a manager or CAB) simply doesn’t work to increase the stability of production systems, measured by the time to restore service and change fail rate. However, it certainly slows things down. It is, in fact, worse than having no change approval process at all.

Accelerate, 2017

Pair programming, combined with a comprehensive build and release pipeline to detect and reject bad changes is the recommendation in the industry.

If you keep your code clean during normal times but make messes in a crisis, then you don’t really believe that messes slow you down. If you pair in a crisis but don’t normally pair, then you believe pairing is more efficient than non-pairing. — The Clean Coder

On Pair Programming

Automation

Computers perform repetitive tasks; people solve problems.

Accelerate, 2017

Humans are slow, and prone to making mistakes. We should aim to automate as many of the mindless, repetitive tasks in our day to day work as possible. This frees us up concentrate on solving the real problems.

Testing

Tests get more time consuming, both to build and to run, the greater the scope of testing. We should aim to concentrate our testing efforts where we will get the most valuable, immediate feedback.

Continuous Integration (CI)

The idea is simple: every time anyone makes a change in their part of the project, grab that person’s new code, and whisk them and their new code through a full build-and-test cycle, just like you would before creating a final release version.

Build early, build often, build everything, build always!

CircleCI - code-building service suffers total credential compromise

High-performing teams integrate with the main branch often. We use trunk-based development, and short-lived (< 1 day) feature branches when necessary. If a change is going to break the build in trunk, we prefer to know about it sooner rather than later. A build breakage is the teams responsibility, and should be prioritised accordingly.

CBOI: Continuous Build, Occasional Integration

Trunk Based Development

Tools and practices that enable trunk-based development

Branch By Abstraction - UML sequence diagrams

Continuous Deployment (CD)

Deployment to production is the ultimate form of feedback. We will not truly know if something is production ready until it is there. We should be able to deploy to production on any day, at any time, safe in the knowledge that our processes, tooling, and automation will right any potential wrongs.

💡 This doesn’t mean that we should expect to be deploying on Friday afternoons and then immediately checking out. Rather, if we cannot feel confident enough in our processes to deploy *at all* on a Friday afternoon, we should take this as a sign that there is something we can improve. — The above is still broadly true - but we (as the humans behind the code) are still ultimately responsible for how our stuff works in production - so we should observe it working.

All of the other items on this page are oriented around assurance of quality before software arrives in production, but we should also invest in our visibility of the health of production systems.

Continuous Delivery

Jez Humble: Continuous Delivery - Sounds Great But It Won’t Work Here

Running experiments