If you ask a hundred consultants what Agile is, you’ll likely get 100 different answers.
So, here’s my answer. Agile software development can be summed up by the first principle of the Agile Manifesto, which states, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
To my mind, that statement says it all. In order to provide early and continuous delivery of valuable software, we must abandon the Waterfall process. Instead of building to a release, we must build to a feature.
This means that instead of doing all the design up front and then code and then test, we identify a high priority feature and build it from start to finish. We write the code but instead of letting it sit there as we build other features, we take that feature and integrate it into our system immediately so that we can see it interacting with the other features of the system to get a true measure of our progress. This is what continuous integration means, to continually integrate features as we build them.
I think that continuous integration is the most valuable and important process for Agile software development because it provides the context and infrastructure for all the other Agile technical practices. It is the central part of a healthy Agile software development process.
But continuous integration is a discipline that many teams are doing wrong. The purpose of continuous integration is to continually integrate code as it is written into the system. Integrating new code means that the new code is then is part of the build with the rest of the code in the system. That’s what “integration” means.
Unfortunately, I see a lot of teams use continuous integration tools but are not doing continuous integration. Instead, they create a system where every team member builds features in their own branch of the version control system and then, just before release, they take those branches and integrate them together. This is called Waterfall software development!
If developers build features in their own feature branches, then they are putting off integration just like we did in the Waterfall process. You may think I’m nitpicking or describing edge cases but many teams I see are stuck in this trap. Even GitFlow, Git’s recommended workflow, advises setting up continuous integration with long-lived feature branches, which I advise against because it defeats the whole purpose of continuous integration. I strongly recommend GitHubFlow over GitFlow for designing a true continuous integration system with Git.
But then how you integrate features that are still being worked on while they are being built? The answer is to use feature flags.
Feature flags, which are sometimes called feature toggles, are a really simple concept that can be implemented in several different ways. One easy way to implement feature flags is with conditional statements. If we’re still working on a feature that is not ready to be consumed by the customer, we simply hide it behind a conditional statement that makes the feature inaccessible to the user interface. That way, users cannot access the feature and they don’t see it but it’s still part of the build.
Having the feature still be part of the build is critical because it can still be compiled, and we can still run it and test against it, and if there are errors or issues with the feature then we can often find them quickly. All of our development tools still work, and we can see how the feature interacts with the rest of the system and when were satisfied that it works correctly, we can flip the feature flags that make the feature active in the user interface so that users can start to work with it.
Feature flags help isolate features, just like branching. But unlike branching, feature flags allow the code to be integrated into the common code base which means that we are really doing continuous integration and getting its benefits by continually integrating our code without branching.
Previous Post: « What’s Agile Software Development?
Next Post: Continuous Integration Requires the Right Tests »