Continuous Delivery

Is an excellent book by Jez Humble and Dave Farley. As usual I'm going to quote from a few pages...

Software delivers no value until it is in the hands of its users.

The pattern that is central to this book is the deployment pipeline.

It should not be possible to make manual changes to testing, staging, and production environments.

If releases are frequent, the delta between releases will be small. This significantly reduces the risk associated with releasing and makes it much easier to to roll back.

Branching should, in most circumstances, be avoided.

Dashboards should be ubiquitous, and certainly at least one should be present in each team room.

One of the key principles of the deployment pipeline is that it is a pull system.

A corollary of having every version of every file in version control is that it allows you to be aggressive about deleting things that you don't think you need... The ability to weed out old ideas and implementations frees the team to try new things and to improve the code.

It should always be cheaper to create a new environment than to repair an old one.

The goal of continuous integration is that the software is in a working state all the time... Continuous is a practice not a tool... Continuously is more often than you think.

The most important practice for continuous integration to work properly is frequent check-ins to trunk or mainline.

Ideally, the compile and test process that you run prior to check-in and on your CI server should take no more than a few minutes. We think that ten minutes is about the limit, five minutes is better, and about 90 seconds is ideal.

Enabling developers to run smoke tests against a working system on a developer machine prior to each check-in can make a huge difference to the quality of your application.

Build breakages are a normal and expected part of the process. Our aim is to find errors and eliminate them as quickly as possible, without expecting perfection and zero errors.

Having a comprehensive test suite is essential to continuous integration.

You should also consider refactoring as a cornerstone of effective software development.

Building Microservices

Is an excellent book by Sam Newman. As usual I'm going to quote from a few pages...

Because microservices are primarily modeled around business domains, they avoid the problems of traditional tiered architectures.

Microservices should cleanly align to bounded contexts.

Another reason to prefer the nested approach could be to chunk up your architecture to simplify testing.

With an event-based collaboration, we invert things. Instead of a client initiating requests asking for things to be done, it instead says this thing happened and expects other parties to know what to do. We never tell anyone else what to do.

We always want to maintain the ability to release microservices independenty of each other.

A red build means the last change possibly did not intergrate. You need to stop all further check-ins that aren't involved in fixing the build to get it passing again.

The approach I prefer is to have a single CI build per microservice, to allow us to quickly make and validate a change prior to deployment into production.

No changes are ever made to a running server.

Rather than using a package manager like debs or RPMs, all software is installed as independent Docker apps, each running in its own container.

Flaky tests are the enemy. When they fail, they don't tell us much... A test suite with flaky tests can become a victim of what Diane Vaughan calls the normalization of deviance - the idea that over time we can become so accustomed to things being wrong that we start to accept them as being normal and not a problem.

All too often, the approach of accepting multiple services being deployed together drifts into a situation where services become coupled.

Most organizations that I see spending time creating functional test suites often expend little or no effort at all on better monitoring or recovering from failure.

Developer on Fire

Recently I was honoured to be interviewed by Dave Rael, the man behind Developer on Fire.
Click the image below to listen :-)