Editor’s Note: This post was originally published on Seattle 2.0, and imported to GeekWire as part of our acquisition of Seattle 2.0 and its archival content. For more background, see this post.
By Anthony Stevens
This is the second in a series of blog posts I’ll be writing on Seattle 2.0 about the “tech” in “tech startups”. Last week’s post talked about source control ; today I’ll discuss another key element in your arsenal, Continuous Integration.
Continuous Integration (often referred to as “CI” – pronounced “see eye”) is the process whereby new software that you produce is built, tested, and (optionally) deployed to the team as soon as it’s written. The primary goals of Continuous Integration are:
- Ensure that defects are identified as early as possible
- Ensure that your software is kept in “production ready” condition at all times
- Ensure that the software you write is not hampering the ability of someone else on your team to contribute to the codebase.
- Reduce the amount of time you need to take to get from idea to delivery
So how does Continuous Integration work? The workflow is generally something like the following:
- I write some new software code.
- I commit it to the source control system.
- A trigger fires that alerts the Continuous Integration system to start.
- The CI server gets the latest version of all the code, including the code I just checked in.
- The CI server builds* my software.
- The CI server runs automated tests* against my software
- The CI server automatically deploys* my software to some staging site or system
- The CI server alerts me and the team if it found any problems.
A few implications. The first one is that you’re using source control – and if you aren’t, start. The second is that you have a separate CI service. There are several good ones out there, and I’ll talk more about that later. The third, and most important, is that you can define what “good” means for your software.
This third implication – that you can define what a “good build” is – varies according to the programming language you’re using, the development methodology, and the testing methodology, and it gets complicated. First of all, not all programming languages are compiled, and so Step #5 is not something that makes sense. Second, and more problematic, not everyone writes code with automated tests in place, and so Step #6 may not make sense for you.
Having said that, it’s my very firm opinion that you should be writing automated tests against your codebase from Day 1 of your startup journey, but that is a different blog post.
Third, and finally, you may not have a staging website or system in place, so Step #7 may not make sense.
Does a CI system have to have all three of those components? Compile, Test, Deploy? Absolutely not. Of the three, though, Test is by far the most advantageous component. It’s a wonderful feeling to know that every time you add new lines of code to your software that your ENTIRE codebase is going to get tested and alert you if you have problems. And for compiled languages, the presence of Test implies that you’ve been able to Compile, so you’ve knocked off two out of three.
Deploy – Step #7 – is a definite nice-to-have, but it’s not critical IMHO. Having said that, I think a lot of startups underestimate how much effort is taken to deploy their software assets – website, middle tier, database, resources, scripts, batch jobs – and could gain a lot of time back if they spent more time on automating their deployment. Again, this is a separate blog post.
Let’s talk for a minute about the pragmatics of setting up a Continuous Integration system. You could roll your own. Write a script that checks your source control system every few minutes, and, if it finds any changes, gets the latest bits, compiles, runs tests, and deploys. I’ve seen enough homegrown systems to know it can be done. However, tooling around CI and SCM (software configuration management) has gotten so much better over the last decade that there’s no reason to roll your own.
My favorite system, and the one I’ve personally been using for a couple years now, is TeamCity, which was created by JetBrains. This has all sorts of hooks available for power users, but is easy and intuitive for those just getting into Continuous Integration.
I’m curious to hear your experiences with Continuous Integration – both as a practice, as well as your feedback on specific tools or frameworks. Share in the comments!
