Thank God for Build Automation

I feel very grateful for having started my career in tech when I did. The “downside” is that there are a lot of tools that I eventually want to learn. The good news though is that there are SO many tools available to me. I can’t imagine what it was like storing code on punch cards, writing HTML without CSS, or coding without an IDE and I am grateful that I will never have to find out.

No, just no.

Today the concept that I am particularly grateful for is build automation. It just makes project management so much easier. But firstly, it’s important that we define build automation. Build automation is a practice of automatically compiling, packaging, and testing code after it has been submitted to a version control system. So with that in mind let’s take a step back and then come back to that definition.

We know that one of the key components related to the Dev Ops lifecycle is continuous integration. To better appreciate just how important continuous integration is think of the opposite, or infrequent integration. In the past, infrequent integration was a lot more common and it was a painful process, to say the least. Teams of developers would work together for an extended period of time on a new feature with that feature being relatively isolated from the main code base. Then, when they would try and integrate their changes into the main code base a mountain of conflicts and discrepancies would inevitably arise.

As one can imagine, sorting through this mountain of conflicts was a very time-consuming process. Even if one managed to resolve these discrepancies in record time the code would still have to be tested for bugs before it could be integrated into the main code base. Perhaps at this point, you’re thinking, “Well so long as the code is bug-free the feature is good to go.” In response to that, if you ever want a good laugh you should find a software developer and ask them what it takes to write bug-free code in one try.

In contrast to infrequent integration, continuous integration allows developers to integrate their code with more frequency and in a more incremental fashion. With that in mind let’s come back to our definition of build automation which is: a practice of automatically compiling, packaging, and testing code after it has been submitted to a version control system. As we can see, build automation is a vital process that facilitates continuous integration in the context of the Dev Ops lifecycle. Although there are many build automation tools the one I would like to now focus on is Apache Maven.

Apache Maven

Maven is an open-source, Apache project that was released on July 13th, 2004. It is a tool that can now be used for building and managing any Java-based project although it can be used with other languages such as Ruby, Scala, and C#. When the creators of Maven were working on their project, their primary goal was to allow a developer to comprehend the complete state of a development effort in the shortest period of time. Maven accomplishes this by providing a uniform build system, quality project information, and guidelines for best development practices.

In every Maven project, you will find a project object model(POM) file. The project object model file is an XML file that contains information about the project including a description of the project, the project version, its developers, and other information. In addition, the POM file can be used to provide configuration settings for the Maven project. A simple POM file can be seen below…

<project xmlns="http://maven.apache.org/POM/4.0.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd"> 
 
 <modelVersion>4.0.0</modelVersion> 
 
 <groupId>com.javatpoint.application1</groupId> 
 <artifactId>my-application1</artifactId> 
 <version>1.0</version> 
 <packaging>jar</packaging> 
 
 <name>Maven Quick Start Archetype</name> 
 <url>http://maven.apache.org</url> 
 
 <dependencies> 
   <dependency> 
     <groupId>junit</groupId> 
     <artifactId>junit</artifactId> 
     <version>4.8.2</version> 
     <scope>test</scope> 
   </dependency> 
 </dependencies> 
 
</project>

<! -- Credit to JavaTPoint for the following sample POM file -->

In particular, you’ll notice at the bottom of this sample POM file how the developer specified which dependencies they wanted to use by means of the dependencies, dependency, groupId,artifactId, version, and scope elements. With every Maven project, there exists a variety of dependencies and plugins one can use to configure their Java project as they see fit. For more in-depth information about Maven, I encourage you to visit their documentation page.

The information takes some time to digest, but it’s absolutely mind-blowing that Maven was created and is currently maintained by a group of volunteers. And yes, I will admit that I am biased toward open-source software but I digress. Instead, I’d like to now talk about Intuit’s experience with Maven because I think it’s pretty cool.

Intuit Customer Success Story

One notable example of a company migrating to and benefiting from Apache Maven is Intuit. While Intuit is most famous for QuickBooks the company also offers technical support, financial supplies, electronic check conversion, and other business services. For many years, Intuit used ANT to build its Java projects. But with time the company began to look at other options so that it could streamline its software development cycle and reliably share open-source components that were made in-house.

To solve this problem Intuit chose Apache Maven and another piece of software named Nexus to manage the repositories that Maven would be accessing. After a transition period following the adaption of Maven, Intuit began to standardize its use of Maven across the company. This resulted in increased team productivity, increased stability of their development infrastructure, and increased reuse of its open-source components between multiple teams. In conclusion, by switching to Maven and Nexus Intuit was able to establish a complete continuous integration system that included both testing and analysis tools. Pretty impressive for a piece of open-source software.

Thanks for taking the time to read this. Feel free to leave a comment and follow me on Medium. Also, feel free to connect with me on LinkedIn!