Continuous integration practices

- In our last video, we talked about three different degrees of continuous delivery of software. We talked about continuous integration, continuous delivery, and continuous deployment. You want to think of these as building blocks on top of each other, each one of 'em depend on the previous step being implemented and adopted correctly. To get started on this video, let's return to Jez and Dave's guidance of keeping our software working all of the time. In this video, we'll go over six practices that we think are critical for getting continuous integration right. In a continuous integration build system, on each commit there's an automatically triggered build that takes the entire code base, builds it, runs all the unit tests, other code validation steps, and packages and artifact at the end along with a build status and a log. If the test fail, the build is broken for the entire team. To fix the build requires the new change runs through the exact same process. This discipline generates a fast feedback loop. For any code flaw it promotes write at automated tests and reduces rework. There are six practices I think that are important when doing continuous integration. Let's get to 'em. The first practice, all builds should pass the coffee test. The build should take less time then it takes to get a cup of coffee. Now I'm not talking about that cold brew that the hipsters like these days, and I'm no barista, so for practical purposes, let's call this five minutes. The longer a build takes, the more people naturally wait until they have a larger batch of changes, which increases your work in progress. The second practice, commit really small bits. Seek to commit the smallest amount of code per commit. Small changes are much easier for everyone on the team to reason about. It also makes isolating the failures way easier. Oh yeah, failures, okay, that's going to bring us to practice number three. Don't leave the build broken. When you leave the build broken, you block delivery. I often suggest the team get together, make a pact. You want to delay meetings or stop all other work until the build is fixed. Now this is really purely a cultural problem and how you handle broken builds, that sets a tone for the rest of your delivery culture. Okay, speaking of culture, that's going to lead us into practice number four. You want to use a trunk-based development flow. Now I know that this is actually going to be quite a hot topic for some people, but I'm going to go there anyway. There are two main practices people use when developing: branch-based and trunk-based. Trunk-based means that there are no long-running branches and the trunk, also called master, is always integrated across all the developers by its very nature. Now, all developers work off trunk and commit back to trunk multiple times a day. Now, instead of keeping separate code branches, developers branch in code and use feature flags. I've worked in both branch-based and trunk-based styles and I would highly recommend using this trunk-based approach. It helps keep work down to a limited work in progress, ensures that code is reviewed and checked frequently, and reduces wasteful and error-prone rework, especially when you're trying to merge branches. The state of DevOps reports specifically identifies this practice as a hallmark of high performing teams. All right, let's move on to practice number five. Don't allow flaky tests, fix 'em. Have you ever worked somewhere where there were tests that sometimes failed and sometimes passed for no real apparent reason? I have, and it was not a ton of fun. You have no way to know if you can really trust the build. Speaking of trust, that's going to bring us to practice number six. The build should return a status, a log, and an artifact. The status should be a simple pass/fail, or a red/green. A build log is a record of all the tests run and all the results of the run. The artifact should be uploaded and tagged with a build number. This adds trust, assures audibility and the immutability of the artifacts. All right, that's the six practices. Hopefully these will help you jumpstart your continuous integration efforts.