Top 5 Build Management Tools

These days in software industry the process of software development very much rely upon best practices of various tools. The software development teams use various tools like project management, release management , test management and various others. As we already discussed about these tools in our previous posts. But, today we are going to discuss about Build management tool. This is one of the most important tool which required in any kind of software development. In this article we are going to discuss about Top Build Management Tools.
But before that let’s have a quick overview on Build management.
Build management is actually a process of collecting all the components in a software release, performing all the automated tasks to compile, build and test the system and then deploy onto the development and testing environments in preparation for staging. It has become an important part of software development in testing process.
But you can not simply do build management without tools. it is also important to ensure that tools are selected properly and thoroughly so that each of them provides the desired service.
So, without wasting any time let’s have a look on top 5 build management tools
1. Apache Maven
 Apache Maven
Maven is an open source build management tool which is distributed under Apache License. It is basically used for Java projects. let’s have a look on key feature of Maven tool
Key Features
  • Open source
  • Based on Project Object Model or POM
  • Release management and distribution publication
  • Coherent site of project information
  • Instant access to new features
  • Extensible with plugins
  • Works easily with multiple projects simultaneously
  • Simple project setup

2. Gradle



Gradle is also an open source build management tool which is distributed under Apache License. It is written in java and groovy supports cross platform. Let’s have a look on key features

Key Features
  • Open source
  • Designed for multiple projects
  • Supports incremental builds
  • Rich API
  • Mature ecosystem of plugins
  • Ease of migration
  • First build integration tool
  • Declarative builds and build-by-convention

3. Apache Ant


Apache Ant
Apache Ant is also an open source build automation tool which is distributed under Apache License. It is also a Java based build tool. Let’s have a look on key features
Key Features
  • open source
  • Ease of Use
  • Independent Platform
  • Can execute test scripts and test suites
  • Can copy files to at different locations
  • Supports Junit 3, Junit 4, Testing etc.
  • Able to compile java based applications
  • Can check out the code from version control system (SVN, GIT, CVS etc).
4. MSBuild
MsBuild or Microsoft build tools as its name indicates it belongs to Microsoft which is written in C# and supports .Net framework and available under MIT license.
Key features
  • Able to build Visual Studio projects without Visual Studio IDE installed
  • Now bundled with Visual Studio
  • Multitargeting
  • Description language – XML
5. FinalBuilder
Finalbuilder is a build tool which supports Windows platform and it is developed by VSoft Technologies in the year 2000. It is available under Proprietary license.
Key Features
  • It can present your build process in a structured manner
  • With FinalBuilder you don’t need to edit xml, or  write scripts
  • Allows builds to be scheduled to run daily, weekly or whenever you wish
  • Extensive library of pre-written actions to automate every common task in build process
  • Integrated Debugging
  • Detailed Logging
  • Version Control Integration
Do you agree with this list? If not than feel free to respond in the comment box with your own take on the top build management tools. One more thing, I would like to add here, if you need help to learn all these build tools or DevOps courses than scmGalaxy can help you in this. scmGalaxy is a community of DevOps professionals who are well experienced in this domain. So, feel free to reach us.
Tagged : / / / / / / / / / / / / /

Build Configuration Templates in Teamcity | Teamcity Guide


Going meta with Meta-Runners in TeamCity

We have seen that build runners can be very handy. Even though most build runners can be replaced with an equivalent command using the command-line runner, build runners come with the convenience of easily setting up build steps, along with the necessary agent requirements and parameters.

Meta-Runners provide a straightforward way to create custom build runners. Meta-Runners can be thought of as a way to avoid duplications in build steps across build configurations.


While templates can be used to create and maintain build configurations that are very similar, Meta-Runners can be used across build configurations that perform the same build steps. Moreover, a build configuration can only be based on one template, but it can make use of multiple Meta-Runners.

In Chapter 3, Getting Your CI Up and Running, we created the deploy-to-test build configuration that deploys the Django application to Heroku. Using this build configuration as an example, we can see how we can extract a Meta-Runner Deploy To Heroku that can be used by any build configuration that wants to deploy to Heroku.

Recall that the deploy-to-test build configuration had a simple command-line runner that executed the following commands:

git remote add heroku  git push heroku master

To create a generic Meta-Runner out of this, we need to provide a way to push to any remote, rather than just


Deploying to Heroku using remotes needs the ssh keys to be set up on the agent. The example used here just illustrates Meta-Runners and may not be ideal for production use.

As mentioned in Chapter 6, TeamCity for Ruby Projects, we can use a gem such as heroku-headless (

As expected, we will do this by extracting the remote out into a build parameter. The command-line runner will have the following as the Custom Script to be run:

git remote add heroku %heroku.remote%  git push heroku master

We will provide the value for the %heroku.remote% parameter in the Build Parameters section of the build configuration.

Now we are ready to create a Meta-Runner from this build configuration. This can be done by clicking on the Extract Meta-Runner button in the right-hand side bar of the build configuration settings page. This brings up the Extract Meta-Runner dialog, which is shown in the following screenshot:

Going meta with Meta-Runners

In the dialog, we give a name to the Meta-Runner. This is the name that will appear in the Runner Type field when configuring a build step for a build configuration.

Click on Extract to create the Meta-Runner. Once the Meta-Runner is created, we can see it listed in the Meta-Runners tab on the project administration page. We can also edit the Meta-Runner to fine-tune it as desired.


A Meta-Runner is essentially an XML configuration (much like most TeamCity configurations) that can be edited directly from the web interface.

The following screenshot shows the edit page of the Deploy To Heroku Meta-Runner that we just created:

Going meta with Meta-Runners

The Meta-Runner extracts all the parameters and steps defined in the build configuration. We can edit the Meta-Runner to have only the necessary parameters and steps.

Using Meta-Runners

We can now use the Meta-Runner that we created pretty much like a normal build runner. We will remove the existing build step in the deploy-to-test build configuration (from which we extracted the Meta-Runner) and add a Deploy To Heroku Meta-Runner-based build step.


We can also disable build steps if we don’t want to remove them while experimenting.

In the New Build Step page, for the Runner type field, the newly created Deploy To Heroku Meta-Runner is available, as shown in the following screenshot:

Using Meta-Runners

Once we choose the Deploy To Heroku Meta-Runner, we can see that the heroku.remote parameter is one of the fields to be configured. Since we created the Meta-Runner with the heroku.remote parameter with the value, that remote is available by default. The Deploy To Heroku runner configuration page is shown in the following screenshot:

Using Meta-Runners


It is possible to remove the value for parameters in the Meta-Runner XML so that no default values are present for the fields.

We can click on Save to add the build step. The new build step, based on the Deploy To Heroku Meta-Runner, will function in the same way as the previous build step based on the command-line runner.


Of course, the value of Meta-Runners becomes more apparent when we create them out of multiple build steps. The same set of steps that may be repeated across multiple configurations can be extracted into Meta-Runners.

Reference Book – Learning Continuous Integration with TeamCity by Learning Continuous Integration with TeamCity

Tagged : / / / / / / / / /

Build Management Recommendation – Build Management Guidance


Recommendation from Microsoft’s Software Configuration Management Best Practices

Build Management Recommendation

Recommendation for Defining a Build

  • Define terms in your development process, and keep a glossary of them on an internal build Web page. If you like, standardize on the definitions in this chapter.
  • Clean build your complete product at least once per week, or every day if possible.
  • Use incremental builds on a daily basis if clean builds are not possible or practical.
  • Start charting the quality of your product, and post it where everyone involved in the project can see it.
  • Release LKG (or IDW) builds weekly; then switch to daily releases toward the end of the shipping cycle.
  • Follow the Software Development Flow diagram.

Recommendation for Source Tree Configuration for Multiple Sites and Parallel (Multi-Version) Development Work

  • Create the mainline (public) and virtual build labs (private) codelines.
  • Make sure the mainline is pristine and always buildable and consumable. Create shippable bits on a daily basis. Use consistent, reliable builds.
  • Build private branches in parallel with the main build at a frequency set by the CBT.
  • Use consistent reverse and forward integration criteria across teams.
  • Be aware that dev check-ins are normally made only into a private branch or tree, not the mainline.
  • Know that check-ins into a private branch are only reverse integrated (RId) into main when stringent, division-wide criteria are met.
  • Use atomic check-ins (RI) from private into main. Atomic means all or nothing. You can back out changes if needed.
  • Make project teams accountable for their check-ins, and empower them to control their build process with help from the CBT.
  • Configure the public/private source so that multisite or parallel development works.
  • Optimize the source tree or branch structure so that you have only one branch per component of your product.

Recommendation for Daily, Not Nightly, Builds

  • Hire a consulting firm to come in and review your processes and tools.
  • Start your build during the day, not during the evening.
  • Publish the build schedule on an internal Web site.
  • Release daily builds as sure as the sun comes up, but make sure they are quality, usable builds. Don’t just go through the motions.
  • Discourage build breaks by creating and enforcing consequences.

Recommendation for The Build Lab and Personnel

  • Set up a build lab if you do not already have one.
  • Purchase all necessary hardware, and do not skimp on quality or number of machines.
  • Keep the lab secure.
  • Show a lot of appreciation for your build team. They have a difficult job that requires a special skill set and personality to be successful.

Recommendation for Build Tools and Technologies

  • Use command-line builds for the central build process.
  • Use Make or ANT for non-Microsoft platforms or tools.
  • Use MSBuild for .NET builds.
  • Use VCBuild for non-.NET builds.
  • Write your scripts in an easy language such as Perl or Batch files.
  • Learn XML because it is ubiquitous.

Recommendation for SNAP Builds—aka Integration Builds

  • Develop your own integration build tool to be used as a precheck-in build test to the golden source trees, or wait for Microsoft to release a tool similar to this one. Keep the points in this chapter in mind when you’re building this “silver bullet.”
  • If you deploy a Virtual Build Lab process, require that the VBLs use a SNAP system to stay in sync with the Central Build Lab. This is the whole concept of an integration build system such as this.
  • Do not rely on the SNAP system as your mainline build tool. Although I mention that some groups at Microsoft use this tool as their Central Build Team build tool, this can be a little problematic because the check-in queues can get really backed up.
  • Understand that no magic tool is out there to do your work for you when it comes to builds and merging code. But SNAP is a good tool, and some groups at Microsoft cannot live without it.
  • Make sure you have all the other processes down in this book before trying to roll out a SNAP system. These processes include source tree configuration, build schedules, versioning, build lab, and so on.

Recommendation for The Build Environment

Here is a short list of what the build environment example in this chapter is about. If everyone is using the same batch files to launch a build environment, re-creating a build will be less painful.

  • Keep the build environment consistent, and control it through the Central Build Team’s intranet Web page.
  • Use batch file commands similar to the ones used in the examples in this chapter.
  • Enforce through checks and balances in the batch files that everyone is using the published project build environment.

Recommendation for Versioning

What I recommend is to read and re-read this chapter to make sure you fully understand everything in it and to grasp the importance of reliable versioning. Here is a short list of what you need to do:

  • Use a four-part number separated by periods for your file version string.
  • Increment your build number before starting each build.
  • Avoid the use of dates in the build number.
  • Use your build number for the label in sources you just built.
  • Don’t try to include product marketing versions in your file version string.
  • For .NET programmers, don’t link assembly versioning to file versioning.
  • During your setup program, do the following:
    • Check for the OS that you are installing on.
    • Avoid copying anything to the system directory.
    • Copy all components to the same directory as the executable.
    • Avoid installing older components over newer ones.
    • Make a copy of any component you overwrite.
    • Use a self-extracting executable to update.

Recommendation for Build Security

With all the talk about security on the Internet and in the applications that are out there, we must not forget about keeping company “jewels” safe. Here are some recommendations that were covered in this chapter:

  • At a minimum, use the four-layer approach talked about in detail in this chapter:
    • Physical security— Doors, locks, cameras, and so on.
    • Tracking source changes— The build process.
    • Binary/release bits assurance— The tools process.
    • IT infrastructure— Company-wide policy and security.
  • Consider the .NET platform as a means of security.
  • Look into software restriction policies that are in Microsoft Windows XP and Windows Server 2003.
  • Start worrying about security before a breach occurs.

Recommendation for Building Managed Code

You will find that building projects for the .NET Framework is a bit different than the classic “unmanaged code builds” that have been around before Web services were ever dreamed up. I went over the parts of building .NET code that tend to trip people in this chapter; the following is a quick list of recommendations:

  • If you build managed code, learn the basic terms of the .NET Framework and the compilation process explained in this chapter.
  • Use delayed signing when developing your project to avoid having to sign the assemblies in conjunction with your daily build.
  • Understand the risk of exposing your developer’s machine to external attacks because of the skip verification list that is created when delaying signing.
  • Decide what is the most practical way of setting up your solution files for your .NET projects. Then enforce whatever policy you come up with through your CBT.

Recommendation for International Builds

Here is what is done at most of the bigger groups at Microsoft and is thus our preferred way of internationalizing our products.

  • Write single binary code as the first step toward truly world-ready products.
  • Implementing a multilingual user interface that allows users to switch between all supported languages is the next logical step.
  • Write Unicode-aware code and create satellite DLLs for your language resources to make these goals much easier to achieve.

Recommendation for Build Verification Tests and Smoke Tests

Some of the general points of the chapter are:

  • Run Visual File Information and VerCheck on each build.
  • Establish a quality bar that the build will be measured against
  • Let the test team own the BVTs, but let the build team run them.
  • Automate BVTs and smoke tests.
  • Track BVT results on a public intranet page.
  • Know the difference between BVTs and smoke tests.
  • Always have the testers or developers run the smoke tests, not the build team.

Recommendation for Building Setup

To improve your setup reliability the following should be done:

  • Decide which setup tool you will use: Wise, InstallShield, WiX, or another brand.
  • Track all files in your product in a spreadsheet or, better yet, a database. If you are using WiX, the files are listed in the .wxs file.
  • Build setup every day, and practice deploying your product to test machines every day. Do not release the build until setup has been created successfully.
  • Start pushing the setup responsibility back to the developers who own the modules.

Recommendation for Ship It!

The following list should be done as the final steps to shipping a great product:

  • Define what and when shipping is for your group. Follow Jim McCarthy’s Rule 21.
  • Start restructuring source trees before you ship, not after.
  • Establish a standard release process for your group.
  • Release a new build process after you release.
  • Add the shipping process time to the product schedule.

Recommendation for Customer Service and Support

From reading this chapter you should understand why you need to:

  • Create and invest in a strong support organization.
  • Make sure your support group has good paths back to the developers but are not intrusive to them doing their work writing code.
  • Outline specific escalation paths in support that give useful feedback to the product group.
  • Involve your support group as early as possible in the WAR meetings to discuss impacts.

Recommendation for Managing Hotfixes and Service Packs

A lot in this chapter was specific to VSS, but I think when you read this chapter you can draw parallels to the source code control tool you use and just copy the basic architect. These recommendations can be followed with any source code control tool but is more specific to VSS.

  • Use sharing to reuse common code modules.
  • Use labeling to isolate and mark different builds.
  • Use share and pin with branching to create new minor releases.
  • Use cloning to create new major releases.
  • Remember: Sharing is the first step of branching.

Recommendation for Suggestions to Change Your Corporate or Group Culture

  • Follow the seven suggestions to change or create a successful culture:
    • Involve as high a level of management as you can when rolling out new processes or tools. In fact, have the executive send the e-mail on the new announcement.
    • Hire a consulting firm to come in and perform an analysis.
    • Match company values to what you are trying to accomplish.
    • Do the math.
    • Not worrying about getting fired gives you incredible power.
    • Never take no from someone who does not have the power to say yes.
    • Publish policies, processes, and tools on the intranet!
  • If you can’t get 100 percent behind what you are doing, you should find something else to do or somewhere else to do it.

Recommendation for Future Build Tools from Microsoft

Looking into a crystal ball that predicts the future, you should see:

  • Adopt MSBuild as soon as possible.
  • Start researching VSTS and see if there are tools you can implement in your current build process and future processes.




Tagged : / / / / / / / / / / / / / / / / /