Jeff Carouth :: Beta

With Continuous Integration, Who Needs a Manger?

Wed Jun 11, 2008 at 14.12

For anyone who is not familiar continuous integration (CI) is basically the practice designed to leverage automated testing and to continuously (usually daily, sometimes more) integrate changes from multiple developers using a build tool. To be successful and useful the code being integrated should be fairly well tested; meaning, something Martin Fowler refers to as "self testing code." However, one could undertake the practice and slowly introduce the comprehensive test suite as the days go by. (Notice I didn't leave any room for the lazy route of not having the test suite?).

The role played by the CI server is to on a set interval, in reaction to code updates, or on a combination thereof run a build process that incorporates testing to ensure the code checked in by each developer meshes with the overall project and does not violate the rules set forth in the unit tests. By doing this after each commit, the server verifies the stability of the code and basically stamps the product as "working". Does this remind you of what your manager is supposed to do? Is (s)he routinely (daily) checking on your and your colleagues progress and making sure everyone is on the same page? Does (s)he verify that your project is meeting the original goals of the project? Can he/she at any given time produce metrics to show the amount of code that is successfully passing tests, the amount of code that is untested, or the number of times checked-in code causes a problem in the build? Chances are, probably not. But with the help of this type of tool the answer will quickly become yes.

What I've found in my time working with (under) a CI server is I am constantly aware of what my development efforts produce. I know that once every two hours a daemon on my machine will run a script that checks my source control repository and compares the current working copy to the copy in version control. If the copy under version control is newer than the working copy the CI server runs a build script which runs the unit testing complete with a generated coverage report, runs a script to create documentation from code commenting, and copies the newly developed files to the development webserver where they can be viewed as if in the production environment. I know that I missed the mark and only have 83.0 percent of my code base covered by unit testing. I know that I've had 37 successful and 4 failed builds which shows me that 90% of the time the code I've checked in to the repository is well-tested. The other 10% of the time I must be in la-la land.

In various positions I've held meeting frequencies have varied from monthly to weekly, but never have I had the pleasure of a bi-hourly accountability like I do with my CI server. I say all this to tell you that not only is CI a great tool to help take care of some otherwise time-consuming and mundane tasks but it is also a wonderful driving force to create better development habits and more stable code.

• Tagged:
• technicalarticles
• php