17

I've been thinking about CI and automatic builds a lot lately and am interested in knowing if there are any best practices for setting up and maintaining a continuous integration environment. Do you keep all your CI related files checked in with your project source? How would you usually structure your CI and build files? Any tips are welcome!

ire_and_curses
  • 68,372
  • 23
  • 116
  • 141
Kristoffer Ahl
  • 1,661
  • 2
  • 18
  • 36
  • allot fo CI things are platform independent but the how do you structure your CI and build files part of your question might be influenced by the platform. Do you care to share what your platform is? – olle Aug 29 '09 at 16:00
  • I'm living in a .NET/Windows environment. At the moment we are using Cruise Control .NET, MSBuild and NAnt for our builds. – Kristoffer Ahl Aug 30 '09 at 07:59

5 Answers5

8
  1. Start with a one step build. If you don't have that, you can not have any reasonable CI
  2. If it isn't in source control, it doesn't exist
  3. If setting up and maintaining your CI exceeds the effort of setting up a developer workstation then you are overly dependent on your IDE or your project structure is overly complicated. Consider that as a refactoring opportunity.
  4. You don't need anything fancy to do CI. You don't even need to know what it is to do it. I wrote about my earlier experience here, when I implemented a naive CI before I ever heard the term CI.
Community
  • 1
  • 1
sal
  • 23,373
  • 15
  • 66
  • 85
3

If you haven't already, definitely check out the Continuous Integration book from the Martin Fowler series, by Duvall/Matyas/Glover. It covers all of the questions you ask in depth with solid examples.

Nightfirecat
  • 11,432
  • 6
  • 35
  • 51
John Feminella
  • 303,634
  • 46
  • 339
  • 357
2

There's also the Pragmatic Series' "Pragmatic Project Automation".

Of course, all files required to build have to be checked in. How else would CI get at them?

I've used CI with Java, so that means an Ant build.xml and either Cruise Control, Team City, or Hudson. It's possible for the build.xml to be generic if you stick with a consistent directory structure for your projects.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • Yep. You'll need to install several things on your build server, but the goal is to have all of your CI-related files under source control (and to have the CI server pull the files from there). We use TeamCity for C# development. If a build gets complex, we use NAnt (which can call MSBuild, too). – TrueWill Aug 29 '09 at 16:51
2

Kohsuke Kawaguchi, the founder of the popular Jenkins/Hudson CI tool, just published a white paper you might find helpful. 7 Ways to Optimize Jenkins

lwells
  • 75
  • 1
1

If your build script starts getting big you can split it out and include the relevant parts. This makes maintenance and readability better.

My other advice would be unlike traditional programming - when making a build script make use of liberal amounts of comments.

Finglas
  • 15,518
  • 10
  • 56
  • 89