navigation
 Wednesday, August 06, 2008
What is Continuous Integration?
I will start by talking a little bit about continuous integration (CI), why it is important and the best practices for approaching it.

CI is the concept that if you and your team are constantly building your code and executing tests against a living copy of your development project, problems that arise are caught very early, are easily identifiable and more easily fixed than a problem that is only discovered at the beginning of a QA cycle.  That basic idea is that every time you check in code, the project will be rebuilt and all of your tests will be run against it and the team, and specifically the developer that checked in the change before that CI run, will see a report of any build problems or failed tests.  At that point, examining your test failures should either tell you that the behavior is expected and you should update your tests, or the code change has introduced a bug or regression and it can be fixed right then and there.  There are a lot of ways of accomplishing this, such as running an ant script on a schedule program of some sort.  There are some advanced software for CI, Such as AutomatedBuildStudio and CruiseControl, that allow you to set hooks on things like source repository check-ins that will kick off a build.

Why is this important?  There is a man named Martin Fowler who says,  "Bad tests are better than great tests that are never run."  A big problem companies have with their development environments is, even if they have tests, they often stop running them because they break and it takes time to fix them, or maybe because they are afraid of what they are going to find.  Sort of like being afraid to open that bottom drawer in your refrigerator because you are afraid there might be some bad tomatoes in there and you don't want to have to clean it up.  Problem is, you leave those tomatoes in there longer and the problem gets worse.  So, those tests practically don't exist, they provide no security for your code.  So, who cares how bad your tests are, run them every day, every code check-in, not only will you be more confident about your code but your developers will be more aware of the impact of their code changes.  With that confidence and awareness, it gives you more flexibility to refactor code that you would otherwise think, "We're not touching that class with a 10 foot pole."  Also, with your tests covering a large percentage of your code you can start your QA cycle much earlier in the development process and your QA engineers will have more time to focus on things like compatibility issues rather than running through manual functional testing procedures.

Here are some best practice techniques that you can use in your CI environment.  We have mentioned kicking off builds each time source is checked in.  Writing tests is an essential part of CI as well.  You could have a CI build that merely compiles your project and gives you an all clean at the end, but what does that really tell you?  Michael Feathers says, "Legacy code is code without tests," and this is a good rule to live by.  As soon as you check in code that you cannot cover with tests, you are already afraid to change it and already afraid that a change elsewhere in your code will cause a bug that you will never catch.  Every time one of those bugs happen, it blows by the developers to your QA department, you increase the cost of finding and fixing that bug by a factor of about 10.  It blows by the QA department and is discovered by your customers, your cost has now increased by a factor of about a thousand.  If you had a test that pointed out the change in behavior in that unexpected location immediately after your developer checked it in, your cost is a mere fraction of what it could be.  So here's the big one: Write tests for everything!  For every bug that is entered and then fixed, write a test that will fail before the fix is implemented and passes afterwords.  Write tests while you write code, maybe even dip into the world of TDD a little.  Next, make the status and health of your CI builds viable and known.  I have seen at Google big LCD screens on the wall that shows a switchboard style of status panels with different color codes for each possible status of a project.  Here is a great article on developertesting.com about using lava lamps to indicate build status.  Be creative, be loud, fun, annoying!  The point is to let everyone know how things are going.  Finally, everyone has to buy into this idea.  If you let it lapse even a little, it's really hard to get back on the treadmill to get it back in shape.  Everyone has to trust that the whole idea is worth the time and effort and it'll pay off in the end, and from experience, it does!

posted on August 6, 2008  #    by Aaron Rhodes  Comments [0] Trackback
Related posts:
Unit Testing with Visual Studio 2008
Falafel Software Releases Official Courseware for AutomatedQA's TestComplete
Using TestComplete with .NET Assemblies.
Load testing classic ASP.NET applications with TestComplete
Improving TestComplete's Error Logging Message
Using Selenium's WaitForCondition feature
Name
E-mail
Home page

Comment (Some html is allowed: a@href@title, i, strike, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):
Live Comment Preview

Copyright © 2003-2008 Falafel Software Inc.