Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm new to continuous integration, but immediately realize its value, and I want to get one set up right away. I have played with TeamCity and have it working in a VM great.

Now, I don't want to spend money on another system, so I was planning on just doing the VM again on a faster machine (i.e. my dev system). There are a few questions that come to mind with this:

  • Hard disk allocation - how big should it be? Sure, 60GB seems like more than enough, but people also used to think that we'd never need more than 64KB of RAM
  • Backups - is it even important to back up the integration server? Sure, I guess it's nice so that one doesn't have to go through the entire configuration process again, but I would think that's about it. I could snapshot my VM every time I do a configuration change, and then do a backup of applications only (ignore the buildAgent stuff).
  • Migration - if I want to go away from a VM on my dev system, to a new server, which maybe even runs Windows Server 2003, is it easy enough? Perhaps this is a particular point best suited for StackOverflow.
share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

As far as I understood your point:

  1. Hard disk usage depends on how big the codebase and how often commits are made and how often the builds are made.

  2. Backups should include configuration and build scripts only.

  3. Probably migration could be the easiest when you migrate from *nix version of CI-server to win-version (e.g., when you migrate from linux version TeamCity to windows version of TeamCity). CI-systems do not implement any standard of some abstract continuous integration specification. And if you plan to migrate, for example, from TeamCity to Atlassian Bamboo, of from CruiseControl to Hudson is like to set up the CI-system from the scratch. The only generic thing for them is VSC-repository to take data from.

share|improve this answer
    
For #1, our codebase is tiny right now, but you never know. I think in TC commits don't really matter because the code gets overwritten by the build agent each time. However, the number of configurations per project might make a difference. If #2 and #3 are easy enough, then I guess it's not much of an issue. For #3, I will stay on Windows for sure, so it's just a question of whether or not it's possible to "package" everything up and then move it over. –  Dave Mar 26 '10 at 17:08
    
#3- I think it depends on CI-implementation. How easy it is possible to set it up and put configs which were previously backed up. –  igorp1024 Mar 26 '10 at 17:14
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.