A beginner question, bear with me: I'm just wondering under what circumstances one should use a build tool like nant or msbuild? I'm working on a medium sized application (.net 3.0), every developer is doing his work and builds on his machine checking his code changes into the repository as he goes. Once we're all done, I'll get all the code from the repository, make a clean build on my machine and we deploy the binaries. Just out of curiosity, where comes the build tool in?
When to use a build tool?
Asked Answered
The short answer is always.
Each developer should be building using the build script before checking code in. The people building the release should be using the build script to build the release. Your buildbots should be using the build script to build and test the code that's been checked in.
Doing this allows all the developers, testers and buildbots to have a consistent, repeatable build. After all, The F5 Key Is Not a Build Process.
Isn't this a bit too harsh? Is it really worth it e.g. spending 20 mins on a build script for a 2 days one-man exploration project that once finished will be archived and never seen again? –
Woodhead
@ddimitrov: yes, it is worth it. I'd wager 99% of the time, that "2 day exporation" will end up becoming some vital piece of production code (probably an internal tool, not a product, but still vital). –
Gladden
The codinghorror link is broken, and now redirects to the main page of the site. The article referenced can be found at blog.codinghorror.com/the-f5-key-is-not-a-build-process –
Daudet
@EldritchCheese Fixed. Thanks. –
Coronado
In what way would it help to have a build script. Assuming resources/dependancies changes? –
Strachey
It sounds like you are using an IDE to do your build. It essentially is a build tool; you are already using one. You should switch tools when the one you are using becomes more of a problem than a solution.
A build tool should be used when your process for building becomes longer than one command. It should be used to get your standard build process back down into one command. If your build process is longer than one command, then you have the opportunity for errors to creep in from missed/duplicated/incorrect commands being done during a build.
When you start doing releases or when your build exceeds certain number of manual steps (you'll notice when it starts getting annoying.) I've written an old blog entry on this topic which you might find interesting.
I think any non-trivial application needs a 'build tool'. We use the term Continuous Integration where I work. There are very exceptional cases (e.g.: I'm building a sample app to learn how feature X works), but aside from those, you'll never regret having a solid build process.
I guess that if the development team was made up of one person... I'd still set up a build system including a repository, a building tool, and multiple suites of tests. Yes, maintaining the build system costs time and money, but it will pay off (I've been working for 40 months now on a project that started with 6 developers, and includes about 30 developers now; it did pay off for us a number of times) in terms of quality control, and the sooner quality issues are detected, the cheape they are to fix.
Continuous Integration (something I'm currently helping implement at my current job) is a bit different from just having a build tool, although it is impossible to do without an automated build :) –
Daphne
If you want to automate anything it's good to use nant/msbuild. For example: 1. check in 2. build 3. test and code coverage
Are you developing with Visual Studio? In that case, you are already using msbuild, since that is the underlying build engine of Visual Studio. Actually, a Visual Studio project file is nothing more than a msbuild script.
Apart from that, you can use the build engine on a dedicated build system, so that your binaries can be built unattended and without having Visual Studio installed. You can also use that for unit-testing.
Agreeing with and expanding on zacherates' answer ... Yes, you should always have some repeatable build process. While technically Visual Studio projects are MSBuild files, it's better to have the "official" build process be separate of the development environment.
In my mind, this is true no matter how big (or small) the team is. I use NAnt and CruiseControl.NET at home, where all I tend to work on are scratch projects and experiments. At work, we use a similar setup, but a bit more structured in how the NAnt scripts are put together.
It's definitely worth your time to look into it. It's not a cure-all, but it is a best practice for knowing exactly which build was released when, and what's in the wild. Being able to identify your compiled code is half the troubleshooting battle! :)
© 2022 - 2024 — McMap. All rights reserved.