Once we define what we want and build the smallest increment, we want to integrate it into our system as soon as possible so that we can see it working and get a true measure of our progress.
Continuous integration is at the very heart of every Agile project and so I wanted to introduce it as early as possible. To me, it’s the third central pillar of agile software development. Continuous integration means having a fully automated build that not only compiles and runs a system but also fully tests it without the need for any human intervention.
When teams learn how to create a reliable build with dependable unit tests then they find that their confidence in their system goes way up and developers are able to freely change, refactor, and extend their code without the fear of constantly breaking it.
This is one of the main values of continuous integration, the ability to get instant feedback when you add a feature to know if it breaks anything in the system. With that level of instant feedback, you can immediately back out your changes if it breaks something in the system. This means you always have a buildable system.
When I worked on a Waterfall development team many years ago we used to fear integration. We put it off as long as possible to the end of our project because we knew it was painful. Continuous integration takes an entirely different approach. Instead of putting integration off, we do a little bit of integration every day, several times a day, in fact, and by doing so we turned what used to be a burden into a tremendous asset.
Agile and Scrum talk about all sorts of different kinds of feedback. We get feedback from our customers. We get feedback in our retrospectives. But to me, the most valuable kind of feedback we get in A
The following seven blog posts are based on Seven Strategies for Agile Infrastructure from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.
These next seven posts discuss some of my favorite tips and tricks on setting up a dependable and easy to use
The other thing that I find valuable about Agile infrastructure and focusing on it early, is that it creates a context for all the other Agile technical practices. Having a build server that is able to invoke a suite of unit tests gives us a space to create unit tests. And when we make the build easy to use it incentivizes developers to use it and then they will. And when they do, not only will they benefit greatly but so will their organization.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Measuring Software Development.
Previous Post: « Measure Efficiency of Feedback Loops
Next Post: Use Version Control for Everything »