This post is the second post in a series on how CI will help a development team. The first post talks about the benefits that CI will bring to the team. (CI = continuous integration)
So you have decided to try and introduce CI into your team? Good choice! This can be a pretty tough time for you. You will need to justify any cost and infrastructure required and you may face questions about the choices you make. You should not let implementation of CI impact your day to day role or the company may question where your time is being spent. CI should be quick and easy to get running and then projects be moved to it over a period of time.
Below are some of the hardware options to consider when introducing a CI environment to a team/company:
If you manage to get yourself a full server setup for your first CI implementation then I am very jealous! Servers cost money to buy, setup and maintain so you have either done a great job of selling the benefits or your company have really bought into the entire concept. Or both! Good work!
Spare Development Machine
If you can’t get a server and there is a small budget available then I would suggest getting yourself a development standard machine to start using. This only needs access to the network and source control. IF there is 0 budget available but you have an old development lying spare then use that instead. This will be plenty powerful enough to run CI tooling and is a common starting point.
If you can’t get a server or a physical development machine then don’t worry. The battle is not lost here. You can run a VM somewhere (testing server maybe) that will act as a CI server. Of course this will not be hugely powerful, but it is perfectly acceptable to start with this. This is actually all I was able to get by my company. It was cheap (existing infrastructure) and fast to setup (they have a standard way of deploying VMs).
Local CI server
This is my least preferred option. But if there is nothing else you have access to then it will act as a decent starting point. The trouble with running a CI server locally is that the machine may have all the dependencies installed (VS, SDKs etc.) and the process may be able to find any references that would be classed as “missing” on other infrastructure, from the GAC. This could result is false positives when running builds. This can then lead to bum deployments where files or references are missing that can cause hassle for your application.
So how do I choose one?
A lot of the decision will come down to what you actually want to do with it. Lets think of the scenario 30 developers checking in 5 times a day and there is a version control trigger to build on check in then of course we need something that's powerful in order to process these queued builds. The other implication here – build time – but we will talk about that later. It would not be feasible for a local machine to be doing this amount of processing as this would effectively cut your development time. But if you had 2 developers who were doing only a few check ins a day then a less powerful machine is viable.
The tip here is to think about your current setup – good VCS habits mean multiple check ins and lots of developers mean higher spec machine is needed – in this case a VM or local machine may not be viable.
DVCS (git or Hg) can mean less pushes to main repo by developers and less builds required. Thus the local machine or VM could be viable.
Regardless of which option you take, remember the golden rule. CI servers should be as free of installed dependencies as possible in order to mimic the live environments. There will be a later post to talk about installed dependencies.
This article has tried to point out some of the infrastructure choices that we have when initially introducing CI to a tam. It is not an exhaustive list but it is the options I had when I have setup my own environments. If you feel any others should be added then please leave comment and I will update the list.
The next post will talk about the different options available for CI tooling and how to choose the correct tool for you.