Let’s start with an assertion that needs no proof: everybody likes to see progress in what they are doing.
After a hard day on a construction site a carpenter can see results of his work, an artist can see her sculpture taking shape through her efforts, a teacher can sense his students making progress. Any of these can present the results of their work at any moment in time and their employers, customers or clients can see the difference in the work from where it was previously.
So, repeating myself: observing and showing real progress from an effort gives satisfaction and confidence and bolsters one’s will to persevere.
Now imagine yourself making an enormous efforts or paying significant sums of money each day and seeing absolutely NO real change in the project you are working on for… a month… two.. half a year… How would you feel about this and what thought would come to mind?
The fact is the above situation is real world scenario if we’re talking about software development. A typical software release schedule ranges from one to six months. In the interim, a project is treated as “unstable” and can’t be presented until all features planned for the new release are implemented, tested, and stabilized. Project stakeholders have little to do except eagerly wait for the new release. Yes, they can watch how tasks are moving from a project’s backlog into a sprint and then into the “done” column – this might brighten the waiting and show that a project is moving in the right direction. But this is hardly a substitute for the ability to see actual product progress and to try a new feature as soon as it’s implemented and tested.
Wouldn’t it be nice to have a client see her product evolving in real time? Wouldn’t it be nice if a client could check out every new feature while the task ticket is still warm?
I’m talking about Continuous Integration (CI) and Continuous Delivery (CD). Let’s look at how these can be achieved, with an emphasis on the latter, and what mandatory prerequisites are needed to set up Continuous Delivery.
First let’s clarify the difference our terms.
Continuous Integration is a software development practice that requires developers to integrate code into a shared repository several times a day.
Obviously we are not going to present our code repository as evidence of “progress” to a client.
Continuous Delivery is a software development practice in which teams producing software via a feature-based approach ensure that their software can be reliably released at any time.
ANY TIME! That’s what we need!
Seriously, back to CD prerequisites, the dependency chain looks like this:
CD > CI > Automated Testing > Unit tests > Loosely-coupled System Design where each system component can be tested separately by injecting all its dependencies.
Continuous Delivery is the summit of your system, the uber-aerobatic hat trick of software development if you will – it requires all aspects of your system to be done right.
If developers were sloppy in controlling dependencies, if the automated testing strategy was not thoroughly thought through from the very beginning, if unit tests’ code coverage is low and not maintained on daily basis – this means CD is a non-starter because you can’t control the quality of the project automatically (and your vehicle is not ready for aerobatics).
Implementing CD means thoroughly testing each system change. The quicker you can find out if a change breaks something the better. In the ideal case it is very easy to find the root cause of an issue since we already know what change is causing problems and the developer can be notified immediately (and automatically). This takes product quality to a whole new level. And it’s the reason “fail fast” is a key principle of CD.
Graphically, the CD process can be described like this:
In addition to client satisfaction CD brings additional benefits such as
- building the right product – client can test features early and change the project backlog if needed.
- predictable and reliable release schedule - we are always ready for a release. Yes, the set of features implemented for any given release will vary but a stable application can be released any moment.
- high product quality – since the majority of defects are captured in the early stages of development it is easy to identify and fix them.
As for the tools that make CD possible, several years ago there were no options other than custom scripting that would glue together code repository, unit tests, deployment and automation testing. Nowadays we have Jenkins, Hudson, GoCD and similar solutions which can help loads with CD. Just make sure the tool you are going to use has release management capabilities and get clear about how you are going to manage releases since there are going to be a lot of them. You should be able to easily track what features are included in any given release.
This means your CD process must be integrated with your task tracking system: it can be quite tricky, but for most larger project definitely worth the effort! How large? CD is definitely not for small (two or three month) fixed-bid projects. But I would say that having code architected for testing and unit testing from the beginning is good practice for any project. Then, if the MVP debuts successfully in the market and the client decides to continue development – this is the time to invest in CD.
Summing up I want to encourage you – demand continuous delivery from your development team!