Build Tools in Software Configuration Management – An Overview

We discussed about Build Best Practices in our last article in the continuity of our Build Process article.

I am pretty sure, by this time you might have got an idea about the build process and about its best practices. As mentioned build process is one of the most important activity in the field of Software Configuration Management (SCM)

I am not going to discuss and pass my opinion on any specific tool as all the tools are capable to do the build and have their own advantages and disadvantages.

I will just try to shed some light only on some of them, so that you can get an idea about them.

I would suggest please don’t jump onto the conclusion by reading any article, book, product overview to finalize a perfect build tool for your project.

You must first list out all your requirements, technologies, dependencies, build process, platform, etc and try to play with all the relevant build tools before implementing the build tool in your organization.

So lets start with the basic definition of what exactly build tool is doing.


Build Tools allows the automation of repeatable tasks by executing all the tasks in the correct, specific order and running each task accordingly. A build tool is used for building a new version of a program with all the specified requirements in correct manner.

There are plenty of tools available in the market, starting with oldest one “make”, then “ant” & “nant”, “msbuild”, followed by “maven”, “ivy”, now a days “gradle” is in boom and so on.

Each tool has its own limitations, approaches, process, methods, mechanism, support, pros & cons.

In early days, people were using an Unix uitility “make” which was an open source utility. Make uses the build file named as “Makefiles” which automatically builds the executable programs and libraries from source code. It also specifies how to derive the target program.

Then many other build utilities emerged in the market which actually were derived from “make”


The revolution in build automation picked up a high speed when Apache introduced their open source build tool for java based application named as “ant“.  Ant supplies a number of built-in tasks allowing to compile, assemble, test and run Java applications.

Ant uses XML as a build file in which user have to specify and write the order in which all the tasks are performed with desired outcome, by default the XML file is named as build.xml

Ant is better for controlling of build process and is a perfect fit for straight forward projects.

It has very simple structure thus allowing anyone to start using it without any special preparation and knowledge.


Apache has also introduced the open source build tool for .Net application named as “Nant” (Not ant) an year later.  Nant is similar to Apache Ant, but targeted the .NET development instead of Java.


Apache then made and release their first build tool which can resolve the project dependencies named as “maven“.

Maven was introduced to improve some of the problems developers were facing when using Ant.

Maven also uses XML as the format to write build specification with different structure all together and uses project object model (POM) file as a build file.

Maven comes with pre-defined targets for performing the defined tasks such as compilation of code, linking, packaging, etc

To resolve the project dependencies, Maven downloads the java libraries and its plug-ins from one or more repositories such as the Maven 2 Central Repository, (you can configure in the settings.xml file from where you need to fetch the dependencies) and stores them in a local cache.

This local cache of downloaded artifacts can also be updated with artifacts created by local projects and with the public repositories.

Maven is not just a build software – it can assist with testing, produce reports on projects, run web applications and number of other tasks provided by plug-ins.


Apache has also introduced “ivy“, a transitive dependency manager which is a part of apache ant.

Together Ant & Ivy become much more powerful where apache ant do its predefined job and ivy helps with the dependency resolution.

It works in same fashion as maven to resolve the dependencies but its role is very limited to resolve the dependencies and publishing of artifacts.


Microsoft was not behind in the race and introduced their build tool named as “msbuild“. The Microsoft Build Engine (MSBuild) is the build platform for Microsoft and Visual Studio.

msbuild provides an XML schema for a project file that controls how the build platform processes and build the software.


Gradle is newest among all and an open source build utility, which works on the concepts and uses good parts of both tools Apache Ant & Maven.

Gradle provides more flexibility than Maven, but is easier to write and use than Ant.

Its not using the traditional XML and instead introduces its own DSL based on Groovy (one of JVM languages).

Gradle’s ability to manage dependencies is not just limited to the external libraries.

As your project grows in size and complexity, you definitely need to organize the code into modules.

Gradle provides powerful support for defining and organizing multiproject builds, as well as modeling dependencies among the projects.

The best thing about Gradle is that it combines all the best features from other build tools in a single tool.


To conclude, Its purely a project, scm & developers call which tool they would like use in their project to build it.

As i said earlier, before deciding the build tool, the project/scm team should do their own investigation with their project requirement and try to evaluate different tools for few days to find out which tool suits their project requirement and which would be easy/simpler to use and of-course it should be in-budget and efficient as well.


I hope you found this article and the previous  articles about build process as a good insight for the software build.

I will continue with Software Deployment Process in our next article.

Till than, stay tuned with us …..

3 thoughts on “Build Tools in Software Configuration Management – An Overview”

Leave a Comment

Your email address will not be published. Required fields are marked *