Build Tools in Software Configuration Management – An Overview

We discussed 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 activities 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 to any 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 let’s start with the basic definition of what exactly the build tool does.

What is a Build Tool?

Build Tool 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 the correct manner.

There are plenty of tools available in the market, starting with the oldest one “make”, then “ant” & “nant”, “MSBuild”, followed by “maven”, “ivy”, nowadays “Gradle” is in boom and so on.

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

In the early days, people used a Unix utility “make” which was open-source. Make uses the build file named “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 at a high speed when Apache introduced their open-source build tool for java based applications named “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 users have to specify and write the order in which all the tasks are performed with the desired outcome, by default the XML file is named as build.xml

Ant is better for controlling of the build process and is a perfect fit for straightforward projects.

It has a 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 the .Net application named “Nant” (Not ant) a 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 “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 specifications with different structures altogether and uses the 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 their plug-ins from one or more repositories such as the Maven 2 Central Repository, search.maven.org (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 artefacts can also be updated with artefacts created by local projects and with the public repositories.

Maven is not just build software – it can assist with testing, produce reports on projects, run web applications and a 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 the same fashion as maven to resolve the dependencies but its role is very limited to resolving the dependencies and publishing of artefacts.

Microsoft was not behind in the race and introduced their build tool named “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 the 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.

It doesn’t use the traditional XML and instead introduces its own DSL based on Groovy (one of the 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 multi-project builds, as well as modelling 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.

Summary

To conclude, when it comes to choosing a build tool, it’s purely the project’s, DevOps engines and developers’ call which build tool they would like to use in their project to build it.

As we mentioned earlier, before deciding the build tool, the project/DevOps team should do their own research with their project requirement and try to evaluate different tools for a 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 useful and now have a better idea about the build tools. You can also refer to our previous articles about the build process as it provides a good insight into the software build.

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

Till then, stay tuned.