So, these past couple of weeks, I've been tasked with building a build machine.
What's a build machine?
A build machine should automagically build your code project into something that is usable. Actually, the complete flow should be:
- Get Latest Codes
- Build Codes
- Deploy
- Test
- Logging
- Reporting
Since the keyword here is automated, that means a Scheduled Task is involved, to be executed every night so that developers can come in the next day to see how their project has performed overnight and maybe fix bugs that their new code may have introduced.
Developers go home.
Repeat.
For this post, I will concentrate on automating the first 2 tasks:
- Getting the latest codes; and
- Building codes
== THE BUILD ENVIRONMENT ==
Lucky for me, I have a dedicated machine and multiple VMs to play with, so here's the specs of my Build Machine, for a Microsoft .NET Framework 3.5 C# Web Projects:
- A clean install of Windows Server 2008 Standard Full x64
- Set it up with a Role of a Web Server with default IIS7 settings.
- Get the latest copy (in my case, version 3) of Microsoft's Web Platform Installer from http://www.microsoft.com/web/downloads/platform.aspx
- Use it to install .NET Framework 3.5 SP1
Since automating everything will probably involve several different products (eg: SVN, Microsoft Build, Deployment, FTP, etc), executing a single batch file (.bat) seems to be the best bet.
== STEP 1: GET LATEST CODES ==
Getting the latest codes is the easiest of all the above-mentioned steps, if you're using SVN.
The command to get the latest codes is, for example:
svn checkout https://PathOfRepository C:\ProjectPath --username MyUsername --password MyPassword
There are tons of SVN commands and options.
It's well documented and has lots of real-world examples online.
Go Google it for more details.
== STEP 2: BUILD CODES ==
If you've installed .NET Framework 3.5 SP1 correctly and successfully, check out this path in Explorer:
C:\Windows\Microsoft.NET\Framework\v3.5\
You should have a nice MSBuild.exe sitting there.
No need for a copy of Visual Studio to build your project.
To build, use the following line:
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe C:\ProjectPath\MyProject.csproj
Again, MSBuild.exe can either build the Project or the Solution, so this also works:
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe C:\ProjectPath\MySolution.sln
It depends on how your Project or Solution is set up.
You will probably need to tweak your Solution or Project file, by setting up Dependencies or References in Visual Studio (the GUI really helps, instead of tweaking the csproj or sln file by hand) before MSBuild.exe performs the way you want it.
== BUILD TIPS ==
The /target or /t flag
Since I am automating a build for an end-product, I set my /target flag like so:
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe /t:Rebuild C:\ProjectPath\MyProject.csproj
I use Rebuild so that MSBuild.exe always deletes old binaries and dependencies before rebuilding them.
This may take up some extra CPU cycles, but ensures that you are always building and referencing the latest codes.
The /property or /p flag
Again, since I am automating a build for an end-product, I add on my /property flag like so:
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe /t:Rebuild /p:Configuration=Release C:\ProjectPath\MyProject.csproj
This ensures that the build is in a "Release" configuration, rather than a "Debug" build or some unknown, default build configuration.
Also, since this is a clean install of Windows, adding this Configuration=Release might throw an error, with an error message that looks something like a path not found.
(I forgot what was the exact error was).
Look for the missing path in your Development environment and copy it into the build machine. This should solve it.
MSBuild.exe has a ton of options, and is probably documented by developers (read: not user-friendly!) and not many real-world examples online.
Good luck using this tool!
