At first glance, building and deploying applications seem simple enough. But in fact, difficult releases without any confidence or processes backing them are very common. Integration and management of a new deployment can be laborious and fraught with risk. So as team size and volume of projects grow, management becomes more difficult and risk more pronounced. This book is a guide to the implementation of good processes in a .NET environment. Author Marc Holmes focuses on actual implementation, and details patterns and anti-patterns to watch out for. He also provides a practical and in-depth look at NAnt and CruiseControl.NET, and solutions to common problem scenarios. For additional insights, visit the author’s blog, Marc: My Words.
I'm considering writing my own delivery code using PowerShell and/or C#, maybe shelling to NAnt or MSBuild.
Background (P.S. This is a religious issue for some. No insult intended):
One person shop, multiple exploratory projects. As most of us - Now windows and ASP.Net. Considering mobile and cloud.
I've started meddling with NAnt, and have tried to follow Expert .Net Delivery Using NAnt and CruiseControl.Net. The whole issue of "delivery" was put on ice and now it's time to "defrost" it. However, I'm not sure which way to go. From what I've learned:
NAnt is showing its age. It's clumsy: it's much harder to understand and maintain than a modern, OO language such as C#. Even after I've followed the book it seems strange to work in an arcane environment where what you want executed is XML, and looping and inheritance are (as far as I remember before the "ice age") are hard to impossible.
MSBuid is MS specific. I'm not even sure if it would support non MS environment. Team foundation server is expensive.
Even so, they somehow both seem to provide value because on my SO search I haven't heard anybody using their own custom software. However, I don't understand why not use C# and simply call NAnt and/or MSBuild tasks as needed.
My advice is just the opposite - Avoid MSBuild like the plague. NANT is far far easier to set up your build to do automatic testing, deploy to multiple production environments, integrate with cruisecontrol for an entry environment, integrate with source control. We've gone through so much pain with TFS/MSBuild (Using TFSDeployer, custom powershell scripts, etc) to get it to do what we were able to do with NANT out of the box. Don't waste your time.
there's much more to building a product than just compiling it. Tasks such as creating installs, updating version numbers, creating escrows, distributing the final packages, etc. can be much easier because of what these tools (and their extensions) provide. While you could do all this with regular scripts, using NAnt or MSBuild give you a solid framework for doing all this
NAnt as a project is dead, or on life support (last release was 0.86 beta 1, two years ago). It was basically cut short by the release of MSBuild. NAnt was nice, MSBuild is OK I guess, but I feel more and more drawn to write code in, well, a language instead of some XML-based procedural stuff. With XML-based build frameworks the debugging experience is awful and you end up cheating by embedding "scripts" in c# which defeats the purpose of declaration over programmation. Same sad story as XSLT, for that matter.
Some good XML-free build frameworks:
I still use MSBuild since it's the format of csproj files, but for specific stuff I shun building logic in XML (no custom MSBuild tasks).
Don't use C# for building script because you don't want to compile it when you make changes to it.
If you plan to use PowerShell, then take a look on PSake.
If you are XML friendly then go with MSBuild or NAnt. Maybe those build scripts are valuable for you. MSBuild has one advantage: Ctrl + F5 builds this script in Visual Studio.
I have been moving slowly to Rake because it's nicer and Ruby is programming language (which means you can do anything): I blogged about how nice it could be, but you have to translate it or look at code only. If you like that, then you may want to see full script and dependencies.
I've been googling a lot lately trying to find articles, books , or even the correct search terms on more 'agile' web application infrastructure/setups but dont think im currently searching the right terms!
Im looking for an overview of best practices that will take me through how i should set things up with regards to things like automating builds, automating deployment to staging and production, continuous integration, versioning, testing etc. etc.
Im working on a pretty complex online store using .net and have so far started getting to grips with using MSBuild to control my builds and TeamCity running builds after commits to GitHub.
I have been working through the 'Inside MSBuild' book which is pretty cool and also a book on brownfield applications which is actually equally useful for a fresh project.
So im getting to grips with individual pieces but really want some concrete processes to follow.
Any help, greatly appreciated as Im fed up with aimlessly googling!
Sam : )
You're on the right track with TeamCity in my opinion; we tried CruiseControl.NET first and found it required more XML-editing.
There is a book on Continuous Integration in .NET; I have not read it.
There is also Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation - I have not read that either, but Fowler-approved books are generally excellent. There's also an older book in the series on Continuous Integration.
If TeamCity is working for you, I'd suggest studying testing first. One of the major values in continuous integration is automated test-running. I can recommend a book on that: The Art of Unit Testing with Examples in .NET.
My personal opinion is that MSBuild scripts are best left to Visual Studio. If having TeamCity run solutions and NUnit/xUnit tests proves insufficient, you might take a look at NAnt. While it is XML-based, I find it easier to understand than MSBuild.
It's old, but covered everything I needed to get up and running last year.