CI/CD tools for Java developers

CI/CD is the combination of practices for continuous integration / continuous delivery (sometimes also continuous deployment) aimed at implementing the release early, release often strategy without causing the integration hell. Incorporation of CI/CD helps to accelerate time-to-market and facilitate the life of developers, but before everything runs smoothly, we need to

• Change business processes;
• Cultivate the specific CI/CD mindset in the team;
• Utilize tools and solutions for process automation.

This article covers the last-named topic. We will look into the essential CI/CD technologies and solutions for Java development that can be integrated seamlessly with CI/CD tools and processes.

Maven, Gradle, Bazel

Build automation systems are the foundation of all the tools discussed below. Regardless of the solution you use, be it Jenkins or GitHub Actions, some other technology must run the compiler and tests. Moreover, a sound build system can substitute some of these external solutions. For instance, Apache Maven is marketed as more than a simple builder:

“Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project’s build, reporting, and documentation from a central piece of information.”

Maven manages projects through a build cycle, which includes several stages corresponding to the goals of CI/CD processes: validate, compile, test, package, verify, install, and deploy. For each of them, you can use special Maven plugins (hundreds of them are on the Internet) that enable the developers to perform various tasks, from verifying the code in a repository to managing application servers. Writing your plugin, calling the code from other programming languages, or building systems is also possible.

• Although Maven (or any other build system) can implement the CI/CD approach for small projects, larger teams may require greater flexibility and scalability. For instance, Administrators may find a centralized web interface more convenient;
• Developers should have different rights within the project;
• Standard build methods should be accumulated in long pipelines;

And so on. This is where other solutions created over almost three decades of Java existence come into play.

Jenkins

Jenkins is the oldest and most popular server for automating Java processes. Released in 2017 under the name Hudson, it was renamed in 2011 due to a conflict with Oracle. Hudson was transferred to Eclipse Foundation, but the project was closed in 2017.

Jenkins is a classical Java application with a web interface. Its WAR file executed with Winstone (a Jetty 10.0.x servlet container wrapper) can be used on any operating system. This WAR file can theoretically be run with other servlet containers, but such configurations are largely untested. It can also be run in the cloud with Kubernetes if necessary.

Jenkins implements the infrastructure as code paradigm, or to be more precise, delivery pipelines as code. You manage the project using Jenkins Pipeline, which can be created with Blue Ocean UI, a classic UI. Writing a Jenkinsfile and committing it to source control is also possible. Such pipelines can be integrated with various tools, extended with shared libraries, or used with standard technologies like Docker.

Jenkins has an impressively extensive ecosystem: there are thousands of plugins for any taste and task. Writing a custom plugin is also possible.

Despite considerable age, Jenkins continues to evolve and soak up all the new CI/CD trends, thus staying one of the world’s most reliable CI/CD implementations.

TeamCity

TeamCity is a commercial server for CI/CD automation developed by JetBrains. TeamCity competes with Jenkins, and although its source code is unavailable on GitHub, administrators may find it more convenient and performant. 

In the CI/CD world, TeamCity is similar to Apple. The proprietary nature of this product enables its developers to take shortcuts and solve issues innovatively. For instance, Jenkins is driven by thousands of open-source plugins, which is good in theory, but in practice, leads to incompatibility problems, poor performance, and a lack of support for many of them. TeamCity has significantly fewer plugins, but they are all polished, tested, and supported around the clock by the best JetBrains engineers.

In addition, TeamCity offers a great modern web interface, built-in support for Jira, cloud integration (VMware, Amazon, Microsoft, Google), and many other features making it an optimal choice for developers.

Atlassian Bamboo and BitBucket Pipelines

Atlassian Bamboo is the third most commonly used automation server. For many years, it was also one of the most expensive ones. In February 2021, Bamboo Server was deprecated, leaving only Bamboo Data Server with a starting price of USD 1,200 for one remote agent (at the moment of writing this article).

The most advantageous asset of Bamboo is integration with other Atlassian services, including Confluence and Jira, that became corporate standards in modern software development. Although Bamboo has fewer features than other solutions, smooth integration with other ecosystem products makes it no less helpful than Jenkins and TeamCity.

However, Bamboo has lost its position with the appearance of Bitbucket Pipelines, also belonging to Atlassian and integrated into its ecosystem. The solution is similar to GitHub Actions and GitLab CI/CD, with a few nuances. For example, the build process is supported only on Linux, and the free tier includes fewer minutes.

To sum up, Atlassian’s CI/CD solution is useful for companies already using other ecosystem products.

GitLab CI/CD

GitLab is a version control system with a web interface, whereas GitLab CI/CD is a toolset for organizing CI/CD within this system. Unlike Jenkins, where developers operate with external repo URLs, the CI/CD customization with GitLab begins from the project files in the interface, which is very convenient.

The fact that GitLab is an integrated environment with repository management gives it a competitive edge over similar CI/CD systems without version control functionality. If we compare GitLab to GitHub, we’ll notice that they approach the matter differently. GitHub uses GitHub Actions and external CI/CD platforms (Jenkins, CircleCI, TravisCI, etc.). With GitLab, however, these features are integrated and can be run locally.

At the same time, GitLab doesn’t have equal GitHub “actions” but substitutes this functionality with Auto DevOps, a set of pre-configured features and integrations that enable the developers to build, test, deploy, and monitor projects. 

Regarding costs, GitLab implements the open-core model: there’s a free open-source GitLab Community Edition and a more advanced GitLab Enterprise. Developers can install GitLab on-premise for free. On the contrary, GitHub may have free private repositories, but they are stored in the cloud, and on-premise GitHub Enterprise Server comes at a high price. Speaking of the cloud, GitLab can be used for cloud deployments at standard market prices.

GitHub Actions

GitHub Actions is one of the most popular cloud CI/CD services at the moment of writing this article. GitHub is the heart of the modern Open Source community, whose servers host significant volumes of open-source code. So whichever CI/CD solution the platform offers, it is worth paying attention to.

Like in the case of GitLab, GitHub Actions is aimed at building, testing, and deploying projects directly from the repository interface. In the same way, developers describe steps in separate YAML files and assign parameters to a set of predetermined actions. 

One of the exciting features is hosted runners, which enables developers to run their code on virtual machines with the possibility to choose an operating system, install the necessary software, etc. Small open-source projects with private repositories can use these virtual machines for free if they don’t exceed the limit of 2,000 minutes and 500 Mb. Any usage beyond these limits will be billed.

Another remarkable feature is the possibility of loading new actions from the GitHub Marketplace. GitHub Actions has a large community that created thousands of configurations available on the marketplace. For instance, if you want to install Liberica JDK, there’s a free setup-java action for this purpose: you only have to set distribution: ‘liberica’ in its configuration. The beauty of this approach is that the source code of configurations is hosted on GitHub, so anyone can participate in their improvement by creating pull requests.

Azure DevOps

Azure DevOps came out of Visual Studio Team Services (VSTS). Even though both GitHub and Azure DevOps are Microsoft products, they have several notable differences described in the official documentation. Some of these features are absent in GitHub Actions or implemented differently regarding user experience.

For example, GitHub Actions doesn’t allow creating Service connections — abstract credentials for external systems. On the other hand, it is impossible to connect to external cloud providers (not only Azure) without a password in Azure DevOps. 

The complete list of Azure DevOps features can be found here.

In general, GitHub Actions and Azure DevOps have different atmospheres around them: GitHub Actions is more about freedom, open source, and open web interfaces and solutions, whereas Azure DevOps preserves the spirit of a seasoned enterprise solution for the most demanding corporate workloads.

Amazon AWS

Amazon offers multiple products and services for setting up the CI/CD pipeline. Ultimately, any platform used for production deployment becomes part of the continuous deployment process.

Take AWS CodePipeline, for instance, which is a fully managed continuous delivery service integrated into the Amazon AWS ecosystem. It enables developers to pull the code from CodeCommit/ECR/S3, build and test it with CodeBuild, and deploy it with CodeDeploy/Beanstalk/ECS/Fargate. You can also use CloudFormation actions or deploy serverless applications with AWS Lambda.

Although you can push the code to CodePipeline directly from GitHub, the strength of Amazon lies in its internal ecosystem. In AWS, all products are interconnected, which saves users a lot of time and money otherwise wasted on building a complex system of services with good SLAs from scratch.

Interestingly, the system benefits can turn into disadvantages: the company that migrated its workloads to AWS may find it extremely difficult to switch providers due to the lack of direct equivalents and drop-in replacements on the market.

Other systems

We described some commonly used and tried-and-true solutions, but numerous platforms for automating CI/CD exist. There’s a high chance you use solutions from the list below: 

• Travis CI
• CircleCI
• CodeShip
• GoCD
• Drone CI
• Concourse CI
• Buildkite
• Buddy
• Semaphore CI
• Harness
• Codefresh
• JFrog Pipelines

Some offer valuable integrations (similar to Liberica JDK and GitHub Actions). Still, they all support Java so that you can build and test any application, in our case, developed with Maven or Gradle.

The list can go on. Every year, new solutions come to life. Despite only sometimes making it to TOP-10, they often offer unique features or vision (for instance, Concourse views the build process as a distributed Makefile).

So even if you build Java applications with good old Jenkins or TeamCity, it is worth glancing at new candidates occasionally. This way, you may find a better-suited system for your business tasks.

Solutions for Java development integrating into CI/CD pipeline

We looked into platforms that help IT teams build a CI/CD pipeline. But the solutions you use for developing and deploying your corporate Java application — the runtime, containers, additional utilities, — can either enhance or offset the benefits of automation.

BellSoft offers a variety of solutions that can be seamlessly integrated into your CI/CD processes and accelerate them even more:

• Liberica JDK, a Java runtime with the widest range of supported system configurations and multiple installation paths: through container registries (images for all Linux OSs are available), Linux repositories, package managers, or REST Discovery API. You can also get ready instances in several most popular cloud environments.
• Ready container images with Alpaquita Linux (100% Alpine-compatible, musl- and glibc-based) and any Liberica JDK LTS version. These images enable you to build microcontainers to optimize cloud resource consumption, and you can also install additional required packages from the repository such as maven or gradle to fit your workflow. Base Alpaquita images and images for Python and C/C++ development are also available.
• Liberica Native Image Kit, a GraalVM-based native image compiler, which is also available as a container image for musl or glibc.
• Buildpacks to automate the containerization process.
• Software Bill of Materials (SBOM) for BelSoft’s products. An SBOM is an indispensable component of software supply chain security, and it also integrates into vulnerability management practices, enabling the DevSecOps experts to monitor infrastructure security and promptly react to increased risks without disrupting the workflow.

The technologies your team uses for development and deployment are not less important for building a smooth CI/CD pipeline. Select a perfect combination for your corporate IT infrastructure, and you will be able not only to accelerate and automate the work processes, but also optimize resource consumption and increase performance of your project.