Aaron Day (@crazydaysorg) had an enlightening talk about Continous Integration. I wish I had his slides I do! Check them out on the BarcampGr Wiki, because they’re pretty dang good. He covered everything from automated builds, to integration testing, to building docs with your build.
Continuous integration is a development practice where the development team regularly commits and merges their changes into a mainline build tree instead of a branch per feature. Not so much. You can do the work together with it, but it’s harder when you get to automation. The goal is to minimize the complexity of integrating changes. Instead of working on a large feature all on your laptop and after two or three days you check in that whole feature. Before you check in you have to make sure your changes are going to work with the changes they made by doing this regularly.
Process
The process is pretty simple. You have multiple stages, devleopment, ingration, and verification. First thing you do is a source update from your repository. Then you’re going to make your changes. Implment the feature, run your local tests. Make sure they execute properly. At that point you know my feature works. According to the source repository when I started. At that point you’re going to do another update on your source repository. Anything they’ve changed is on your syste,. If two people happened to work on a particular file they’re going to want to integrate those changes. If someone added a function you’re going to want to make sure the changes that theyve done don’t affect your changes,. You’re going to do that by running the tests again. I prefer to run tew hole test suite if we have one. If you only have a particular file you’re going to wind up just running the test cases on the particular files.
Finally you’ve decided my changes are merged I’m now going to commit to the source repository and run the tests again.
Benefits.
Simplified integration. Merging a weeks worth of work is going to take a day. The idea is that I’m going to commit every day, or multiple times a day. That way I’m going to commit code that is fresh in their mind. In theory, the build is always working, or there is a short period of time since it’s worked. It also helps the dev team know how far they are through their current sprint and effort of work. It helps them push their changes out through QA teams. The Manager can pull a build that worked less than a day ago and see how far the team is actually along.
“I think there’s another benefit you didn’t state. The cost of fixing an error grows with elapsed time. By doing this you catch errors sooner. This minimizes the cost of errors.”
Best Practices
Check in early, check in often! Just like politics in chicago. Except don’t check in when you’re dead!
Communicate commits with the team. Hey I am checking in my code and I’m going to be running the build, make sure everything is running until the build is successful. That’s just a good practice. no one wants to do a source update and find that it’s broken.
Don’t write new code when the build is running. We had these cows all over the place and whoever is running the build has a cow on their desk. When they’re done the cow goes back and it means no build is running.
If you broke the build don’t write new code. Yourr build is to fix the build now. Don’t write new code! Don’t say “OK, I broke the build now I’m going to work on something else!” it’s a bdad habit because now you have more changes you’ll ahve to integrate.
Don’t let the build remain broken overnight! THat’s definitely good policy. If you’re there till 8 or 9. COme in early the next morning you’re probably getting too far to think straight. If you let it stay broken overnight then the guys are gonna have problems the next day.
Communicate broken builds with the team. You want to make sure the team knows “Hey! The build is broken! Don’t do an update!” Update the team when the build is working.
Everyone should understandt he build. Not everyone needs to be an expert on how builds work, but they need to know enough that if something is broken I can now at least diagnose what the issue is or hopefully fix the problem. You don’t have to be an expert on your build system. I come from a Java envrionment so peopleall hate me.
“What do you mean by understand” If you’re using Maven to produce your build you should at least understand that if there is a configuration error you can look for and diagnose what the issue is. Understand means know enough to fix what is broken. Not with the software, but iwth the build tool itself.
“I find it’s good enough if people can tell if it’s good or not. They can at least go bug somebody.” Lets say your build is running and your database server is down. I should be able to determine that my build failed because the db was down, not because my code is wrong. OK, the build faild because of this. I know now I can look at it and it broke at hte part it’s connecting to the database.
Checklist
If you’re going to be doing continuous integration. Source Version Countrol Build, Testing, Automation. It’s nice if you don’t have to run over to the build serer and kick off the build.
Source version control you want a sourve cersion repository. SVN is a common one. A database which store revisions of follows and allows retrievals of each version. CDiffin is going to help when you do an update and you see if you want to get the changes in this tree here to make sure that if someone got a partial build. You can find what changed since the last revision that was in there. Branching, tagging are just common features. That’s more how you’ll be doing releasing. Not so much continous integration. I’m kind of a free software geek…ALl my examples are free.
Build
a combination of scripts which compile programs, test the artifacts, and generate installers. you want it to be a single command. If you have to make a test directory before you run the build piut that in your build system itself. That way you don’t ha ea list of things to do before you run your tests. It seems silly and counterproductive. If you have a good system like Make, Ant, or Maven to do that for you. alot of the tools do Incremental building very well. If you do a C file that hasn’t changed since the ojbect file that it generates. I don’t need to rebuild it. I can just go with what I have. Dependenct fetch is something that Maven does really well. It’ll actually fetch your dependency libraries. We use tapestry for one of ours. It willfetch tapestry and all of tapestries dependeniceis. It’s a cool system and helps us not have to check in all the jar files tha aare dependent on the system.
Test
Exercising an applicatin in a controlled environ,ent with specified inputs and states. Observing the outputs and state changes. Verifying correctness by a set of metrics.
Everyone knows what testing is to a degree. Make sure the code works as advertised. There are multiple types. Everyone has different definitions. Unit testing, Functional testing, integration testing is a large something or other. I’m not gonna get into thosse fights. Some tools are xUnit, jUnit for Java, nUnit for .net, CPPunit for C++ code, PyUnit for Python code. Selenium is a great web testing framework. It integrates with your browser but can run tests in a CLI environment. Fitnesse, JMETE we mainly use for our load testing. It works well with integrating to multiple machines.
Automation
Scheduled or triggered build which builds the software, runs thest, generates reports, and notifies participats. Junit results can be integrated in the report that comes from the build. CruiseControl and Hudson. A web interface is convenient so people don’t have to install special software. They can just check a website. You can use RSS, Email, etc. Some of them are distributed. They run a server on multiple machines. When a checkin occurs you wind up triggering a build and the build would run the javadocs on this machine, thestatic code on this machine, the build over here. Some examples are crusie control and hudson. They’re both pretty decent tools. They’re both free. CruiseControl punch it into google. Hudson you will want to punch in HundsonCI.
Advanced Topics:
Staged Build, don’t have a ton of time to put into this. Stage build is something that is going to wind up having a central server where the checkin is going to discover on. It’s going to delegate.
Branch per feature… If you’re going to have an automated tool you’re going to want to….. do cloning of your CI build for the branch you want to work with. I don’t know how I feel about branch per feature and how CI relate. I think there’s a good idea there, but you’d have to clone the build which means that the transparency level is going to be down. The boss needs to look at JOES CI build and that kind of defeats the purpose because you’re still gonna have to merge the code into the trunk.