Introduction

Software is written by multiple teams and dozens of people in corporations that depend on already tested and released software components. This is very different from how students are taught to write software in undergraduate programs, and often the first struggle a new hire contends with is working effectively with the build ecosystem of a company. One of the major components in a build system is the build tool; Maven is the most popular build tool for Java products. Maven is much more than a build tool as we will learn. It can be used to manage an entire project. There are tools similar to Maven that are listed below:

1. Ant
2. Gradle
3. Ivy
4. Gulp
5. Grunt
6. Leiningen
7. GNU Make

We’ll start with the different terms and their meaning in the context of a build system.

Build

In software development, a build is the process of converting source code files into standalone software artifact(s) that can be run on a computer. The resulting artifact is sometimes referred to as the build. In an organization, there are usually several branches of code with varying degrees of stability that result in nightly builds and get deployed in various environments such as stage, test, or production.

Build tool

The process of building a computer program is usually managed by a build tool, a program that coordinates and controls other programs. Examples of such programs are Make, Gradle, Meister by OpenMake Software, Ant, Maven, Rake, SCons, and Phing. The build utility typically needs to compile the various files in the correct order, download dependencies, run unit and integration tests, and any other related tasks for producing binaries that can be deployed.

Artifact

The word artifact is from the Latin phrase arte factum: arte meaning skill and factum meaning to make. In the software development life cycle, artifact usually refers to objects that are produced by people involved in the process. Examples would be design documents, data models, workflow diagrams, test matrices and plans, setup scripts including compiled binaries, and software packages. In most software development cycles, there’s usually a list of specific required artifacts that someone must produce and put on a shared drive or document repository for other people to view and share. Artifact may occasionally refer to the released code (in the case of a code library) or the released executable (in the case of a program). An artifact is the byproduct of software development.

Build automation

Build automation is the process of automating the creation of a software build and the associated processes. This includes compiling computer source code into binary code, packaging binary code, and running automated tests. A build - the process that converts files and other assets under the developers’ responsibility into a software product in its final or consumable form - is automated when a final artifact(s) can be produced without direct human intervention and can be performed at any time with no information other than what is stored in the source code control repository.

CI/CD

CI/CD (Continuous Integration and Continuous Delivery/Deployment) is another commonly used term in the context of builds and build automation. Maven is a small cog in the CI/CD pipeline and it is important to understand the bigger picture of how code lands from developers’ IDE to binaries in production. The underlying goal of a CI/CD pipeline is for teams to deliver code changes more frequently and reliably. A modern-day CI/CD pipeline involves continuous development, continuous testing, continuous integration, continuous deployment, and continuous monitoring of a software application throughout the application’s development life cycle.

The acronym CI/CD has a few different meanings. The “CI” in CI/CD always refers to continuous integration, which is an automation process for developers who are checking in code. Successful CI means new code changes to an app are regularly built, tested, and merged to a shared repository. It’s a solution to the problem, known as integration hell, of having too many branches of an application in development at once that might conflict with each other. A developer checks out a branch and makes their changes, but when attempting to merge the branch back finds too many merge conflicts that take longer to resolve than the time required to make the code change.

The “CD” in CI/CD refers to continuous delivery and/or continuous deployment which are related concepts that are sometimes used interchangeably. Both are about automating further stages of the pipeline, but they’re used separately to illustrate how much automation is happening.

Continuous delivery usually means that a developer’s changes to an application are automatically bug tested and uploaded to a code repository (e.g., GitHub or Perforce). The uploaded changes can then be deployed to a staging or live production environment by the operations team. The goal of continuous delivery is to apply minimal effort to deploy new code. However, with continuous delivery, the buck stops at the code repository.

Continuous deployment picks up where continuous delivery left off. Continuous deployment involves automatically releasing a developer’s code changes from the repository to the production environment, where they are then usable by customers. Sometimes, the term continuous deployment is also used to include the processes of continuous delivery.

Often, the term CI/CD is used to mean all three connected practices of continuous integration, continuous delivery, and continuous deployment. Without being bogged-down in the semantics, it is enough to visualize the CI/CD process as a pipeline that involves a high degree of ongoing automation and continuous monitoring. Maven is a small but important component of the CI/CD pipeline.

Conclusion

Maven has become very popular over the years and the primary reason for its success is that it has defined a common interface for building software. Maven’s intelligence is implemented in the plugins it uses which can be retrieved from the Maven repository. Maven has abstracted common build tasks into programs that can be invoked via Maven and are known as plugins. Plugins are maintained centrally and shared universally and are the topic of our next lesson.