I couldn’t have said it better myself. This is an old topic for Jay and I have to credit him for bringing continuous integration into my own life many many years ago. Back in November he wrote a post about builds “Building Software Is Easy“. He captures the main point, it’s all too often ignored by development in favor of what is believed to be simple solutions.
These ‘simple’ solutions often involve generation of master ‘solution’ files in VS.Net and are horrible to maintain. Projects fall off radar as soon as they are removed, some never get added in the first place. Inter-project dependencies can also become issues that have to be carefully hand-crafted at times between projects. All this speaks nothing about deployment, configuration issues, testing, version control, and build-time dependencies. To say it in one sentence: “These ‘simple’ solutions fall short in every way”.
Ask yourself the following:
- Do you know exactly (version and all) what prerequisites are used to build your software?
- Do you know all the options that are configured for all your released software projects?
- Can you be certain you will be able to reproduce the build a year from now, how about two or three years out?
- Can any machine create a build of your software?
- Do you know what components need to be rebuilt when an interface changes?
I’m not suggesting you write a massive hierarchy of makefiles or one giant NAnt script. This is a problem that can be solved. What it requires is development effort, time, and dedication.
The comment on the post linked above strikes me as more funny, Julian Simpson writes:
My new theory is:
If it’s available from an IDE, developers will take it on. Hence, you can convince Java developers to have a go at an Ant build because there’s usually IDE support. NAnt? Nope, there’s no native support in Visual Studio.
I find it hard to get .NET developers working on the build. Java developers will approach it. I don’t think they’ll refactor build files unless there’s a plugin.
She is probably right here. It’s not fun work, it’s not challenging, it’s not glamorous work, it’s just work.
I’ve seen these issues many different times and solved them many different ways, some worked well, others did not. Recently we are using some C# to crawl the projects and load them with the Microsoft.Build API and enforce the configurations that way. Seems to work well for us in manipulating all the little settings needed correctly and consistently build. We use another tool I wrote some time ago to actually do the build. Yes we again crawl the entire directory for C# Projects, topo-sort the dependencies, and invoke the build programmatically. Of course you could just as easily output a NAnt file or some other script to run the build once you know what to build and in what order.
Regardless of your solution, you will have to put some development time into it if you want the build to solve problems … or … you may be happy with your build being a problem?