Nothing will show your customer that you’re on top of your game better than shipping quality software fast. After all, what customer doesn’t want quality work completed on time? Continuous delivery, the practice of keeping the master branch of your codebase always deployable, is how developers can meet that demand. Discussed in Jez Humble’s book, the practice relies on a continuous delivery pipeline:
The pipeline takes each software commit, and runs it through a gauntlet of stages to test and prepare it for deployment. We should be able to deploy any commit that passes these stages at a moment’s notice. Neal Ford does an excellent job of introducing continuous delivery pipelines in the free sections of his O’Reilly video.
Pipelines vary team by team, but one constant is they need comprehensive and top notch software testing. That can be a formidable obstacle to a lot of teams.
“If you don’t like testing your product, most likely your customers won’t like to test it either.” (source)
Without tests, continuous delivery is likely to become continuous breakages. Worse still, just writing tests isn’t enough. Far too many teams find their tests become a liability. Tests begin eating up more and more time to maintain, ultimately slowing or derailing the team’s continuous delivery goals.
We need to craft our tests to meet specific needs to fit harmoniously within a continuous delivery pipeline. This was one of the subjects discussed at Neal Ford’s continuous delivery workshop at UberConf 2015, which I was fortunate enough to attend.
Whether you already have a continuous delivery pipeline, are beefing up your application’s test suite in preparation, or are just getting started, there are specific continuous delivery testing practices that can help ensure your tests don’t become a roadblock. We’ll cover three such practices over a series of posts. Tune in next week for practice #1: Write tests that provide a ROI.