CI/CD your way: 11 on-prem options for continuous integration and delivery

From Jenkins and GitLab to Azure DevOps Server, these tools bring a CI/CD pipeline to your own server, Kubernetes cluster, or hybrid cloud

CI/CD your way: 11 continuous integration tools for on-prem deployment
Lagarto Film / Getty Images

When a team develops software together, the need for continuous integration (CI)—and often continuous delivery (CD) as well—is rarely debated. The central continuous integration server acts like a referee and a quality control manager by constantly building and rebuilding the software before testing and retesting it. The sooner the CI server finds problems, the sooner they can be fixed.

The real debate is whether to host the continuous integration process yourself or offload the work onto one of the many cloud-based CI/CD services that have blossomed. Letting someone else do the work is always attractive and the services can often be faster because they share a pool of powerful machines that can run the different tasks from the CI process in parallel.

But the downsides can be significant. If your team is especially worried about access to your code or data, keeping everything on a machine that’s in your locked server room brings a warm feeling. Yes, it means updating operating systems and applying patches yourself, but sometimes that’s better than crossing your fingers and trusting someone else will do it.

If your code base is big or you produce large containers full of binaries, moving these bits across the open Internet can be slow. Many of the cloud lovers tend to ignore the latency issues and costs of shipping big blocks of data. If you’re just pushing them to the server room down the hall, you can build out a fast network that will guarantee they’ll arrive quickly. Yes, this may mean fewer pauses in your day to get a cup of coffee, but it can improve delivery time immensely.

One of the biggest advantages may be the chance to add customization to your build. The cloud services do a good job with standard blocks of code configured in the same way as everyone else and they try to offer all of the plug-ins and options, but nothing beats the control of having root access to the machine. There is no doubt that the preconfigured pipelines for many of the cloud options save time, but they can be constraining when you start to walk off the beaten path. The ability to do whatever you want makes an on-prem deployment a compelling option.

Here are 11 solutions for building out continuous integration services on your premises.

Jenkins

The first place many turn is Jenkins, the original continuous integration tool that began life with the Java developers at Sun Microsystems. The Sun engineers were smart enough not to limit the architecture to Java code and today there are thousands of plug-ins that handle many of the raw chores for all of the major stacks and most of the minor ones too. It’s not unusual to choose something random like, say, Lisp and find someone has written a plug-in for it. The fact that Jenkins is written in Java means that it’s generally easy to download the JAR file and run it on a Windows, Mac, or Linux box.

The Jenkins project continues to attract more attention and redevelopment. The Blue Ocean subproject aims to make it possible to configure and optimize the Jenkins pipeline from the comfort of a browser. Less text editing of configuration files and more clicking.

The Jenkins team has been working to make it easier to run the CI server anywhere by lowering the amount of work it takes to configure and update the tool. The Evergreen version will configure, build, and update itself from Docker containers. It’s like a doctor sewing up the bullet wound in his or her own leg.

JetBrains TeamCity

The same company that has nurtured the IntelliJ IDE also offers TeamCity, a combination of continuous integration server and many extras like code quality metrics and a forum for discussing the code. JetBrains has worked to maximize compatibility by integrating TeamCity with all of the major version control systems and creating a big collection of plug-ins for supporting different languages. At its core, TeamCity is Java but it’s easy to make it work with other languages.

The code is built to run in a wide variety of local machines. There’s a Docker container, of course, and a Java JAR file to run in a servlet container, but there’s also a Windows .exe file. One of the more interesting options is the “pre-tested commit” which doesn’t happen on your desktop but still runs through all of the CI steps before the code is officially considered committed. A better moniker might be “two-phase commit” but that doesn’t sound as cool.

The Professional version is said to be “free forever” and comes with all of the features and no limits on users or build time. Those who buy the Enterprise version get extra build agents to run in parallel and these agents can be spread out in public clouds like AWS. It’s a hybrid solution that lets you host the main server locally but spin up cloud machines when you need the extra power.

GitLab CI/CD

Many teams use GitLab in the cloud on GitLab servers, but the stack is open sourced and available to be installed on the server of your choice in your server room. The community edition can be checked out and built directly from GitLab, but it’s probably easier to just grab a package installer for your machine and let it do the work. There’s also a paid Enterprise edition with more features.

The CI work for GitLab relies heavily on Docker for configuration and testing, something that can be faster and simpler than basic tools. Much of the work is handled by a program called GitLab Runner, an autoscaling tool for executing the stages in the pipeline, that can be installed in multiple servers. There’s also a nice feature called AutoDevOps that can look into your code, note the existence of a standard make file, and then configure the pipelines to build, test, and deploy your software.

The entire GitLab stack comes with much more than continuous integration. It also offers version control and collaborative tools for planning, issue tracking, and code review, all big parts of creating running code.

Azure DevOps Server

Microsoft has been working to open up the Azure stack to anyone who wants or needs to host it on their own servers, and the devops corner is no exception. The simplest solution is just to add more build agents to speed up the work. The basic Azure DevOps account comes with a free build agent. You can add more agents by paying Microsoft, the simplest solution, or by installing the build agents on your own machines with packages for MacOS, Linux, and, of course, Windows. You can also get extra build agents with other Microsoft products like Visual Studio.

If you need more control or isolation, the first release candidate of the complete Azure DevOps Server is now available to be installed on your machine. It works with a local version of Azure SQL to offer a complete package.

Oracle Container Pipelines

The former startup Wercker is now part of Oracle, which calls the acquired CI/CD product by the simple but very useful name of Oracle Container Pipelines. It makes sense because the tool is focused on building, testing, and deploying Docker containers using a collection of pipelines full of tasks. If you can spell it out as a Bash script, it can be a task.

There are installable versions for both Linux boxes and Macs, making it possible to run the same YAML pipeline code on your desktop or in a server farm. If you need to use the cloud, well, you’ll need to build it yourself. Oracle prices the service by the seat.

Shippable Server

Shippable’s main offering is CI/CD in the cloud, but if you want to install your own server or maybe just “bring your own nodes,” you can use Shippable Server. Shippable is designed to be a hybrid. You can mix together the components you need to deliver the performance your code demands.

The tool offers native assembly lines that turn code into deployed instances with plenty of testing along the way. The standard build and test tasks form the foundation of the service but Shippable also includes a fair amount of integration with configuration (think Puppet or Chef) and instrumentation for measuring performance of the running deployment and displaying it in a visual dashboard so you can follow along.

Atlassian Bamboo

Atlassian has two different products for continuous integration. Bitbucket Pipelines is integrated into the Bitbucket cloud while Bamboo is software you can download and install on your own server. The two products are meant to be separate and not to deliver a hybrid combination of cloud and local server like some of the other solutions here. If you need more build capacity, though, Bamboo is integrated with AWS to let you spin up instances to handle some of the chores.

Bamboo is a commercial tool that delivers more features than Jenkins with more polish and support. The product ships with a conversion tool that will move the build configuration file to the internal Bamboo format. The Atlassian team has added a number of smart features for watching the code base on your local version of Bitbucket or Stash and detecting when merges can be completed to keep the repository cleaner.

Most of the documentation is focused on supporting Java and .Net projects. Although it’s possible to use the tool for all types of tasks, it is optimized for these two worlds. The product is free for 30 days. Prices after that depend upon the number of users and the number of build agents.

Drone

If you’ve built your code to do everything in Docker containers, then the Drone continuous integration tool is ready to serve. All of the pipeline tasks are executed in containers and then the results can be deployed in containers. There’s an active marketplace full of plug-ins written in Bash shell script or Go that handle all of the standard chores.

You can run Drone pipelines in the cloud or install the software on your servers. Drone is free in a developer edition limited to 10,000 builds per year, though you get most of the major features. Paying for the enterprise version unlocks unlimited builds and options like deploying to multiple machines and major cloud providers.

Codefresh

Codefresh calls itself the first continuous integration platform built for Kubernetes. The builds are done in containers and then the results head right for the clusters you’ve configured. Containers can be cached in the local repository and then the deployment can be guided by Helm charts.

The standard pricing and the free tier are all based upon running the tool in the Codefresh cloud. If you want to create a hybrid or closed version running on your servers, an enterprise version is available. You can try it free for 14 days.

Cake

If you combine the name of the language C# with the old school version of continuous integration, Make, you get Cake, a tool designed for C# programmers who want to write their build scripts in C# too. There’s no need to fiddle around with a different syntax.

Cake is open source and it supports all of the Microsoft-centric tools you enjoy using. It may be the simplest solution for anyone who is largely developing for the .Net world.

IDEs and a repository

The classic integrated development environments like Eclipse and IntelliJ are not what everyone thinks of as a continuous integration tool, but some developers are able to generate most of the same advantages of a good CI tool without maintaining a separate system. The IDEs, after all, will check out, build, test, and even deploy code in containers if you add the right plug-ins. Why duplicate this work?

Avoiding the extra continuous integration server can be a better choice if you don’t need the third party acting like a neutral referee and quality control agent. If your team is working fairly independently on code that isn’t too integrated, it may not make sense to keep the CI server running in the background. It just duplicates the same builds and tests that you’re already doing on your development machine.

On the other hand, if there’s any overlap in the code being touched by members of your team, the extra work of the CI server becomes invaluable. It’s a tough decision to make but there are times when all of the standard options from the IDE offer enough integration and delivery to suffice.

Copyright © 2019 IDG Communications, Inc.