I am using TFS 2008 and Visual Studio and my boss has instructed me to implement Build Automation for Development and Release builds for a web Project.
I am a total newbie in Build Automation.
There are multiple developers working on the project on different machines using Visual Studio 2008 team System. Source is already being maintained on TFS 2008. SQL Server in Use is SQL Server 2000 and hosted IIS is IIS 7.5 on Windows Server 2008 x64.
I have searched over the net and found Continuous Integration and Nightly Builds as two important Build Automation techniques.
I was just wondering of any disadvantages associated with both the methodologies (CI and Nightly Builds).
If someone could guide me to a working tutorial that explains both techniques the it would be quite helpful.
Please also tell the requirements of IIS, SQL Server and any other that might be pre-requisite to implement build automation.
Also i would like to know whether there are other techniques that are better then CI?
Replies and discussion much appreciated.
Thanks
There are no real disadvantages, except that with CI your server will be busier.
The reasons for these builds are:
NB: Every morning you have a fully built release installer that you can test. You know all your code builds, and every day you have a release “ready” that you could send out if you wanted to. This is much better than having a programmer spend a day running through a “how to build a release” document step by step to create an installer every time you’re ready to release a new version! And your testers are able to test a complete release package, so you have confidence that every part of your release and installation process works as it’s getting a daily workout.
CI: This is just a fast build that runs every time someone checks in. It tells you if you check in non-compiling code, so that the author can fix the problem immediately and minimise disruption to other team members. You can waste a lot of time when 4 or 5 programmers get the latest code and then find they can’t do any work for 2 hours until Fred fixes his bad checkin. Knowing about a broken net allows your programmers to avoid doing a Get unless the code has been verified as working.
To implement NBs and CI you first need to get a build that will run on your server.
If you have a running TFS, then to create a build server you just need to install your dev tools (VS2008 and anything else needed to build the code, such as 3rd party libraries/build tools etc) as if it is a developer PC, and it’s ready to use as a build server. Just right click on the Builds folder and “Create new build” and you should be able to figure out most of it as you go. You have to give it a name, set up the workspace mappings to tell it where to build the code, and set up an output folder for the results to be “dropped” into, and you’ll be good to go.
You may need to tweak the setup of your projects to make this work well e.g. developers are terrible at putting references to “C:\Projects…” in their solutions, which often break when the project moves onto the D: drive of a buid server, etc. Also, rather annoyingly the build server will build code into different locations than your dev PCs, so you may find parts of the build process will break and you will have to reconfigure things like fixed locations for references etc so that they work on both Build and Dev machines.
Add as much of the process as you can (clean, get code, build it, run unit tests, obfuscate binaries, sign binaries, build installers, sign installers, copy to deployment folder) automated so that the NB can build everything and you get a fully releasable product at the press of a single button. Computers are good at this stuff, so don’t leave an error-prone and expensive to run human slaving away all day to make an installer!
Set the NB up to do a full rebuild (this should be the case by default) and use the Triggers settings to have it run every weeknight at (e.g.) 1am. The NB should build everything (a good, thorough build).
Copy the NB build settings to make a CI build. In the MSBuild project file, set these properties: IncrementalGet=true, IncrementalBuild=true, ForceGet=false. This will convert it to a fast incremental build. In the Workspace Mapping, Cloak or remove as many folders as possible to minimise the amount of code it Gets from source control, to help keep it fast. Set the build to only build one variant (e.g. Release) so it’ll be a quick build. In the Triggers (right click on the build and edit it), set it to build whenever there is a checkin.
Run the build monitor on all dev machines. This places an icon in your icon tray and give you optional notifications whenever builds start, complete, and fail. If your CI build fails you will then know about it immediately.
Now, you should have a nightly build ready for testing every morning, and whenever anyone checks in any changes, a new incremental build will kick off, and you’ll know within a few minutes if you have broken the codebase in source control.
(We have a third build, which is an incremental Test build. This is the same as the CI build, but it runs all our unit tests as well. This is executed nightly, and developers can trigger it whenever they wish to verify the codebase on the server (we use this as a gating mechanism before promoting to a the test branch). It’s a lot slower than the CI test, which is why it’s not used for the CI build – you want the CI build to finish as fast as possible)
Note: To make the CI work, you will sometimes need to do a full rebuild. In the “Queue Build” dialog, enter these command line options to force this:
There aren’t any techniques that are “better” than CI. You can (and should) use CI in addition to all other processes you implement.