DevOps Zone is brought to you in partnership with:

C# ASP.NET developer who works with MVC but is sometimes known to dabble with WebForms. Passionate coder who cares about his craft. Has a real want to create clean, readable and maintainable code. Obsessed with CI and its effects on a good development team. Pushing the bounds of continuous delivery and studying the advantages it brings to developers. Paul is a DZone MVB and is not an employee of DZone and has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

Considerations when choosing hardware for CI

08.07.2011
| 7973 views |
  • submit to reddit

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:

Server

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.

Virtual Machine

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.

References
Published at DZone with permission of Paul Stack, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Kyane Ben replied on Thu, 2012/03/15 - 11:04am

I currently run TC in a VM on my development machine, not the best solution but helps remove the disadvantage of dependencies being available etc.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.