“...the best thing since sliced bread when it comes to managing projects and their environments...” “...we can now react at the speed of business...” “BuildMaster made us re-think what proper deployment is...” “...we implemented a *real* deployment process...” “...BuildMaster makes sense of incremental builds and their very liquid feature sets...” “...our confidence in the reliability and repeatability of the deployment process has been restored...” “...all of my projects are building wonderfully and are fully integrated into deployment...” “...manual, error-prone deployments are a thing of the past...” “...extremely capable software, especially in an enterprise environment...” “BuildMaster is a great tool for automating the build process, but stands head and shoulders above other tools...” “...this is a very solid piece of software!” “...it's 2:45 AM your time?! Do you guys never sleep?” “BuildMaster is absolutely swell!”

Identifying Changed Files

In theory, your issue tracking system will identify all of the bugs/improvements/features that will go in a release, and your source control system will have commit comments that identify which changesets go to which issue... but theory and reality often differ. It's easy to check-in a change against the wrong issue, or forget to comment at all.

Sometimes the best way to know which changes are actually in your release is to take a "diff" of the code deployed to production and the current development code. That way, you can see every line of every file that changed. For example:

image

This is pretty to accomplish in BuildMaster..Here's a quick walkthrough.

Step 1: Label and Tag Your Builds in Source Control

This is something you should already be doing. But in case you haven't, check out Label and Tag Your Builds in Source Control with BuildMaster. For the record, here's how we label (and then get by label) our source code:

image

Note that after labeling the code with %RELNO%.%BLDNO%, we get the code  to a directory called ~\Src.

Step 2: Get Previous Release's Source Code

To get the previous release's source code, you need to know where it is in source control.

There are two variables in BuildMaster that will help out with this: PREVRELNO and PREVBLDNO. They refer to the last-deployed build in the last-deployed release. For example, we're working on Release 2.6.0 now, so our previous release (which is currently available for download) is 2.5.7. The build that ended up getting released was 12, which means %PREVRELNO%.%PREVBLDNO% will be replaced with 2.5.7.12 at run-time.

Here's how we retrieve the code.

image

Like the previous action group, we're getting by label, but to a directory called ~\PrevSrc.

Step 3: Compare Directories

This just takes a single action called Compare Directories Report.

image

There's not a whole lot of options to configure for this action.

image

And That's That

That's all there is to it. With these few actions set-up, your builds will now have a report attached to them with whatever name you specified.

image

As with all reports attached to a build, clicking the "View Full Report" button will display it in a new window, and produce a report similar to the one shown in the first screenshot.