I’ve spent the last 5 months on a build engineering engagement. Its been enjoyable, for the following reasons:
– The projects I was working with were implemented in .NET so it was an opportunity to explore build techniques that I know from the Java world and see how they apply in .NET
– I was working with several separate, but related, teams and therefore was exploring how to best integrate the projects.
I’m hoping to think about these areas more, but there’s a couple of brief points that I thought were interesting.
Importance of IDE build engineering in .NET
In .NET its worth considering how the IDE fits in with the build environment. Unlike Java based projects we are pretty much guaranteed the IDE is Visual Studio. Moreover, a lot of .NET developers have come through the Visual Studio history, and so are used to working solely within the IDE. Tools like the NUnit Visual Studio Plugin aid this command-line-free method of work for the interactive development process.
All this being said, we must remember that agile development places a premium on repeatable, maintainable, automated processes for tasks outside that of the interactive development flow, such as continuous integration and deployment. Therefore there exists a question of how we marry these 2 worlds together.
The basic premise is that using Visual Studio project definitions within your automated process means that your interactive and automated processes remain closely tied, and updating your project structure through the IDE automatically updates your automated process (so aiding maintainability.)
You can implement this into a NAnt automation setup by using NAnt’s new <solution> task, or by calling Visual Studio from the command line (using the ‘devenv’ application). We do still need to use something like NAnt since VS only covers a subset of what we want to automate, i.e. it doesn’t cover packaging, testing, etc.
What remains to be seen is whether <solution> or calling devenv directly is the best way to go, and how much we do still need a command line environment in the development process (e.g. for deploying an application locally for acceptance tests.)
Managing project dependencies
The other point to come up was how projects relate to each other, and specifically how to manage dependencies between projects. Things to think about are:
– How to specify dependencies in a convenient way
– How to manage build- vs run-time dependencies
– How to manage chained dependencies
– How versioning comes into play, and can we used ‘ranged’ versions with fixed ‘published’ interfaces
– How to allow a project to depend on either a fixed version, or ‘latest’ version of another project
– Where ‘fixed’ version requirements exist, how to perform pre-emptive ‘gump style‘ continuous integration for the head revision of all projects.
– What needs to be tested for each project’s build
I heard someone talking about Continous Integration the other day, and I’d forgotten the value of the simplicity of having ‘one build’ even for a larger team (since these problems become less important). But where you have long build-times and/or different deliverable timeframes it is worth considering breaking up the project. I think this would become a valid option when the agile community has tools and practices to solve the above questions.
Mike Roberts