IV Best Practices: Automating the Release Process with custom MSBuild Scripts

In .NET world MSBuild is the build engine, the guy that transforms your code to binaries. Code is built by interpreting scripts and they hold a sequence of build steps. Usually, the only scripts that are used are project files, like csproj or vbproj files. On build server, you can specify a solution or project file to build. However, it can do much, much more if you use it with custom scripts.

When starting the build, build server (TFS, TeamCity) passes a reference to your sln or csproj file to MSBuild. If you set it to pass the reference to another file, say ‘main.build’, MSBuild will try to interpret it as a build script.

This script can have multiple custom build steps. These could include validation of properties which are passed to script or setting up folders for build output before the build itself.

Regarding the build part, it can simply call another instance of MSBuild to build a solution or few of them and perhaps enforce a specific output directory. After the build script could have a step to run unit tests.

If build and tests pass, script can create a release/setup package by simply copying a set of files somewhere, by zipping them or by running a separate tool for making a setup (ClickOnce, InstallShield etc.). This can also include an obfuscation step for desktop applications.

Script can run your setup package, install your service to IIS web server and/or run scripts to setup database and actually create new environment. If needed, a set of integration tests using tools for automated testing (SoapUI) could be used to verify package as a whole.

Automated cycle from build to deployment can greatly increase confidence in your code, both yours and your client’s. Hence you could come to a point where you automatically deploy to production environment if tests pass. This way you are going towards continuous delivery, an ideal of developers and clients.

Many utility applications (testing frameworks, archiving utilities) support running through command line interface, which are great for running from MSBuild script. Also, many other functions like executing SQL script against a server, or setting up stuff on web/application server are wrapped in tasks built by community. Finally, you can build you own tasks in C# or VB.NET for really special cases.
References:
https://www.soapui.org/
https://www.msbuildextensionpack.com/