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.
that is central to this book is the deployment pipeline.
It should not be possible to make manual
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
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
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
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
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
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
Having a comprehensive test
suite is essential to continuous integration.
You should also consider refactoring as a cornerstone of effective software
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
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.
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.
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
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.
It started out as a joke between myself and Josh (one of the testers at Bluefruit). I had the traffic lights in my office as I was preparing a stand to promote the outreach events (Summer Huddle, Mission to Mars, etc...) Software Cornwall runs. The conversation went on to alternative uses for the traffic lights, I was planning to see if people would pay attention to the traffic lights if I put them in a corridor at the event; we then came up with the idea that we could use them to indicate TDD test status.
Although it started out as a joke I am going to use it at the Summer Huddle, the lights change every time anyone runs a test so it should give an idea of how the entire group are doing without highlighting an individual pair.
The software setup is very simple, there is a Python web server (using the Flask library) running on a Raspberry Pi that controls the traffic lights using GPIO Zero. When the appendTestTrafficLight() function (in run_tests.js.erb) appends the traffic light image to the webpage I made it send an http 'get' request to the Raspberry Pi web server to set the physical traffic lights at the same time.
At the moment the IP address of the Raspberry Pi is hard coded in the 'run_tests.js.erb' file so I have to rebuild the web image if anything changes but it was only meant to be a joke/proof of concept.
The code is on a branch called traffic_lights on my fork of the cyber-dojo web repository.
The hardware is also relatively simple, there is a converter board on the Pi; this only converts the IO pin output connector of the Raspberry Pi to the cable that attaches to the traffic lights.
The other end of the cable from the converter board attaches to the board in the top left of the inside the traffic lights; this has some optoisolators that drive the relays in the top right which in turn switch on and off the transformers (the red thing in the bottom left) that drive the lights.
I have to give credit to Steve Amor for building the hardware for the traffic lights. They are usually used during events we run to teach coding to children (and sometimes adults). The converter board has LEDs, switches and buzzers on it to show that there isn't a difference between writing software to toggle LEDs vs driving actual real world systems, it's just what's attached to the pin. Having something where they can run the same code to drive LEDs and drive real traffic lights helps to emphasise this point.
Last week I broke my Daiwa Spectron spliced-tip rod which has served me for 25 years+.
After some searching around I replaced it with a Drennan Acolyte Ultra 14ft.
I christened it yesterday with my heaviest ever bag on the Tone; 80lb+ of chub and roach with a few skimmer bream, one roach-bream hybrid, and several small perch. All caught on waggler, red/yellow/white maggot, on 1.7lb hooklength, and a size 20 Kamasan B560. Wooohooo.
Once a year a spent a glorious week fishing for salmon on the River Verdal in Norway.
This year, despite the low water, I caught this cracker.
A huge thanks to John Oldren who owns the beat. You will not find a more hospitable host.
Also to Gary Scott for being super helpful as always.