If you have worked on a project for the last 10 years and you have a nicely written (and probably bound) Product Requirements Document, then you’re probably working on a Waterfall project. If you’re too busy to even ponder the first sentence because you’re overly concerned with the ’testing phase’ of the project that’s coming in a few months, then you’re definitely on a Waterfall project.
The truth is most of the IT projects in-flight today use the Waterfall methodology of Plan, Do, Check, Release. These projects measure release cycles in months and sometimes years – not in minutes or seconds like most agile projects. For them, releasing software is a BIG DEAL. After all, they’ve been working on this software for 12-18 months. These teams don’t practice the art of releasing software very often. So what happens when we don’t build the muscle memory to do something? We’re not very good at it. Most Waterfall teams are not very good at releasing software to their customers. Subsequently, the product they produce reflects the fact they’re out of shape when it comes to creating installers, packages and the release process in general.
“We did an analysis of hundreds of projects over a multi-year period. The ones that delivered in less than a quarter succeeded about 80% of the time, while the ones that lasted more than a year failed at about the same rate.” – Forrester
There is a better way …
Whether we like it or not, we’re already living in a digitally disrupted world. Your competitors are likely seeking ways or have already found ways to deliver software to production faster than you. Pace to market will become part of your competitive advantage in this new world.
All of this is the reason why continuous integration is so important. In this new world adaptability trumps rigidity; a key operating philosophy we practice every day at the #EMCDojo. If you’re currently doing ‘agile’ but releasing bi-weekly then you’re not as agile as you think you are, or should be. Teams embracing weekly or bi-weekly deliveries still means that developers are churning out code and builds which sit around like rotting fruit on the dock waiting to be delivered to a grocery store. I contend that bi-weekly integrations or releases are not continuous. Small batch releases are your friend.
Why small releases are your friend?
Continuous integration enables software changes to be pushed to production repeatedly and reliably. Code is integrated as soon as its finished. Incrementally delivering changes enables us to validate our assumptions and the code we’re writing sure, but it also means we don’t have code or builds sitting around waiting to be integrated.
Does continuous delivery mean lower quality? No – in fact it usually leads to higher quality. The pipeline breaks releases down into phases each designed to test the quality of the software that’s being built and delivered. We just shorten this cycle so we can do it rapidly. The pipeline provides visible feedback to the team on the changes they’re making. Feedback happens instantly as the code is integrated.
What does our pipeline look like?
- Build the code
- Run test automation
- Automated deployment/continuous delivery
This all takes place in a matter of minutes.
Note: When the pipeline stops, WE STOP
If you’d like to learn more about how we leverage continuous integration, or how you can get started, come visit us at the #EMCDojo. We would love to give you a tour and perhaps, if you have the time, you could even pair with us. After all, learning by doing is at the heart of everything we do.
Email Brian RocheTags: CD, CI, Continuous delivery, Continuous Integration, incremental, pipeline, release, small