At the core of continuous integration lies collaboration and regular additions to the mainline code stream.
I believe the first step in getting ready for CI is to make sure you can work on the same mainline product code with little to no friction. This is where your version control makes a world of a difference.
I started working with CVS and Borland StarTeam where a modern flow for CI was just…painful. Creating branches for features or fixes during the development life-cycle was so tedious that in many cases you had to fire off a mail and ask if anyone was working on a particular piece of code. Now i’m not saying these two systems aren’t any good, but the tooling and visibility of what was going on in the code base was poor.
I once heard of someone that didn’t check in their code for almost 8 months. Obviously there is a lack of a sense of responsibility here but I can just imagine the fear of committing your code to a central repository if you can’t manage to create branches, labels or tags to keep your changes off the mainline but also safely stored on some remote server.
There is a huge selection of version control systems out there and you need to pick the right one for your protect and team. The main thing here is that the system should work with you and not against you. Some things you can look for in a VCS are:
1. Tooling and support
Do other tools support your VCS? (VCS hosting, IDE integration, Code review tools, build server, etc.)
Can you easily see the activity stream of what team members are doing on the codebase? Are there tools to help with this?
3. Working is parallel
Can you and your team work independently on the same mainline code with minimal effort and reduced conflicts?
I can’t say I have exhaustively compared the top VCSs out there, so my opinion is a bit biased. GIT has reigned champion in my books from the first git pull. It’s my suggestion to you if you are just starting or looking to migrate to something else. The wealth of tools, integration and hosting for GIT is just impossible to ignore. (and it’s free)
From the technical perspective the major requirement is the ability to integrate with a build server or some system that can detect changes in your code repository and kick off a few tasks. It can even be as simple as running a few terminal commands and sending the results via email. Luckily we have much better tooling now than smacking together a few bash scripts. In the next post ill go into the nitty gritty of setting up a build server. For now i’ll leave you with some resources for getting comfy with GIT: