Developer practice vs development practice part 1
Alan Shalloway tweeted “if you want to learn how to become agile at the team level, you still want to consider how the team fits in the bigger picture” and this tweet gave me the push to write about the Continuous integration as a developer practice and CI as development practice. For a while now I’ve been thinking about writing about the two dimensions of CI, not being sure if it’s a good thing to open that discussion on not. But since that one tweet I’m confident I want to dig into this.
In some systems CI can to be approached from two different angles. The developer practice that is on the team level and from development practice point of view, which is more looking at the product as a whole. Let’s look into the developer practice and go through the basics.
Since developers and development team may be working on an isolated part or feature of the system, they might not have the need or use for full system test scope after each commit, which may take long time to execute, but they can work efficiently getting full benefits of CI and still commit to the system level frequently with confidence.
The teams working with the same code base have a CI server running automated build and test continuously every time new code is committed into the repository. Information (=results) from the build and test are displayed on information radiators. The tests on team level CI could be unit test or component test, but these are just the normal examples or developer tests. You should have on the team level every test that the team can execute, maintain and utilize. In some projects/products/systems this is considered normal way of working but this is not, at least easily, applied to certain software industry domains where the test environments can be complex and expensive. From these constraints emerges the need for supporting teams that provide constant feedback from those centralized larger scale, slower pace test areas. (Here we get the first glimpse of development practice thinking but let’s not go into that yet)
What we want to avoid with team level CI is the big bang code commits, since they more probably break the system and it’s far harder to find the actual faults. When making small commits, building and testing continuously it’s much easier to keep the code together. Also in the case that the system is broken, the faulty code lines are easier to pinpoint since the amount of code committed is limited. One thing we’ve adapted to is that we enforce fixing fast rather then removing the faulty code. The experience has been that it’s more efficient to fix the broken main track than revert the changes, go to branch, fix the fault, test, merge back to main, and test again.
If something goes wrong on the team CI build / test the radiators go red and if the system is good enough also the root cause (commit & by whom) is displayed to everyone. Now the priority is to fix it and fix it fast. Here the rule should be “Don’t commit on red” since this may lead to erosion of code quality. On team level this should work since the CI environment is not so large or complex. The – fail fast fix fast – mentality gives you the rhythm and security to work in such a way. If it’s not enforced and accepted as a common practice to fix the broken build or test immediately there is a possibility that the code quality can easily start eroding. Once you let the code degrade, it will take time and extra effort to get back on track.
So there’s the basics of CI as a developer practice and for some this can be the only CI that is even needed. To sum it up, frequent commits, continuous build and test (fast!), information radiators and CI culture in organization.