Mike Lyons explains continuous integration as merging work into a shared repository at least daily with automated tests for fast feedback. Smaller batches and cross-team collaboration improve quality. CI practices apply beyond software, like in Google Docs.
When it comes to agile development and agile teams, it's so much more than just within the team. There's sort of this universe of things that need to happen and coordinate with in order to go from idea to delivery of value. And so that encompasses a number of different components. And it's sometimes referred to as the idea of DevOps. You've probably heard this term, DevOps, it's not a new term, it's been around quite a while and it's sort of an umbrella term for. Just like agile is an umbrella term, it's an umbrella term for a number of different practices and, and techniques. And really it also is a mindset fundamentally. DevOps is the idea of collapsing development and operations. You know, not so long ago the development teams and the operations teams were kind of at odds and oftentimes they would not work well together. Now the operations group typically is all about keeping the system stable and making sure there's great uptime and it's secure and all that. And introducing change into the stable environment was something that was, was not, you know, was frowned upon. It was difficult. It was, you know, almost like, don't change anything. And then the developers, well, you know, they're, they're paid to introduce new things, to build new features and, and when they're introducing new things to the people who are trying to keep change from happening, we have this sort of butting of heads and it was this chasm, this divide between development and operations. Well, DevOps sort of collapses the divide and says, no, we're going to, we're going to work together. So operations, you're going to have to get smarter about development and development, you're going to have to get smarter about operations. DevOps an umbrella term for the universe of people, processes, tools and technologies that need to come together to deliver the thing of value. A piece within that is continuous integration. So continuously integrating is this idea of at least daily we're checking our code into our code repo, we're checking our text into our document repository, we're checking our knowledge into our wiki, we're constantly integrating the things we've been working on all day integrating into our repository. Quite common in software development is we're checking our code in each day and when that thing is checked in, a series of automated tests and techniques can run on that piece of code. Continuous integration, you don't want to go more than a day before you're checking these things back in. CI is about frequently merging the work of multiple people, multiple developers into a single solution. And when we say frequently, we mean continuously. CI is a concept that comes from the software development world, but it applies to many other things. Say, for example, you might use Google Docs or some online cloud mechanism to share work. Well, you and I could be in the same document at the exact same moment working on it and making changes in real time because it's continually being integrated into the source document. And the smaller the batch we use, the better. Smaller batches go through systems, faster frequent integration, smaller batches. And think about the quality gains we're getting. The faster we get that feedback, the better quality we're going to have in our Word document we're working on, in the book we're writing, in the whatever we're getting feedback on, even outside the software development world. So continuous integration, it's all around us. Continuous integration fosters a number of things on the team, including increasing our shared understanding, promoting frequent feedback cycles, increasing quality, promoting testability, and fostering collaboration across different skill sets on the team. Now let's talk tactically about how this might work on your Agile software development team. Here are some practices to consider. Developers make frequent commits of working code to their controlled common code repo. That common repository build is triggered by some sort of check in procedure and then automatically runs. The team gets feedback from that integrated build and then fixes issues. And that process happens over and over continually. Some benefits include lowering our risk profile by this frequent integration. It helps the teams find bugs easier because scope is narrowed to recent changes. The team produces deployable software by enabling this practice. So integrating early and frequently and continually is a practice that you need to start getting used to. And it can apply again not only to software projects, but to whatever you're working on. It's that idea of getting the fast feedback by integrating whatever you're working on frequently.
