Since we wrote the original article just a little over two years ago, we’ve seen a fairly big shift away from self-hosted tools to feature rich Software as Service (SaaS). We’ve also seen nearly all Continuous Integration (CI) tools blur their lines with Continuous Delivery (CD) providing an all-in-one solution.
That being said, finding the right platform to form the basis of your Continuous Delivery is a fundamental principle of the Agile Manifesto, and you really need a solution that is going to fit into *your* existing way of working with minimal effort.
In this guide, we’ll talk about the features to look for to run a successful Continuous Delivery pipeline, and some of the open source, self-hosted and Software as a Service (SaaS) solutions on the market.
Selecting your solution
When choosing your solution, be it SaaS or self-hosted, you need to have confidence that it will offer you and your team a pain free Continuous Delivery workflow.
Factors that can influence this decision will range from the amount of work needed for initial setup, to the time it will take to undertake any ongoing maintenance, and finally how easily it integrates with your PaaS or server infrastructure.
Whilst it’s great to shop around, ideally you want to get it right first time, as you don’t want to invest project time on an “Ok” solution that you will have to migrate away from 6 months down the line.
Let’s talk features
Essential features
Whilst every SaaS or self-hosted solution on the market boasts a myriad of different feature sets, there are a handful of core features that are essential to operating a successful pipeline.
– Integration with version control
Version control integration is the most crucial feature your chosen solution should possess. When I say integration, I mean it should poll your repository, or use webhooks to detect changes, which should then initiate a new build and subsequently trigger the rest of your CD pipeline process.
– Custom script execution
Custom script execution within a pipeline step is a key feature, especially if you deliver a diverse number of projects.
Thanks to buildpacks, many common deployments are very simple, but often the need arises to run custom deploy scripts. In these instances the ability to use tools like Capistrano to execute deployment tasks is vital. While it is written in Ruby it can be used to deploy almost any project, thanks to the open source community behind it.
– A Pipeline
A pipeline view is a visual representation of all of your deployment steps. These steps should all be linear. A single step, e.g. unit testing, could fan out to run multiple tests in parallel. Then any dependent step should be executed automatically once the previous steps have passed. The final step in the process should be a manual one, in order for one of the team to make certain that the build is in a good state before releasing to any publicly facing environment.
– Notifications
As a software engineer, switching contexts can be really distracting so your Continuous Delivery solution should offer an alerting system to inform your team to any successful or failed deploys without them needing to check a web interface.
In a basic form, this can manifest itself as an email, however many Continuous Delivery platforms will also integrate with the popular team chat programs, like HipChat and Slack.
New Features
– Docker support
Container images have replaced buildpacks as the way to assure consistent versions of software releases. Look for baked in Docker support to reduce the complexity and overhead of your pipeline.
We use docker images as a consistent way to provide base image for Rails.
– Pipelines/Workflow
This is the heart of continuous delivery and there has been a lot of innovation in this space.
GitHub, who traditionally are the first step in building a CD pipeline now provides GitHub Actions which allow pipeline functionality from within your source code repository. It provides a similar “look and feel” to IFTTT allowing build your workflow visually.
Circle CI have turned workflow steps into shareable packages called Orbs.
The “deploy anywhere” approach of Microsoft Azure Pipelines (part of the Azure DevOps suite) means you can release software to any environment: Kubernetes (Azure Kubernetes Service), Serverless (Azure Functions) and Web. This is, of course, achievable because of the close integration with their Cloud platform Azure.
Using Azure DevOps suite meant we could commit new features through source control (VSTS) and deploy onto Azure Kubenetes Service (AKS) with relative ease.
Heroku Pipelines’ Review Apps allows us to review Pull Requests in a single-use version of the application.
Self Hosted vs SaaS
The argument for self-hosted or SaaS solutions will not be resolved in this article, as both have their advantages and their flaws.
A self-hosted solution for example will require a lot more initial set up than a SaaS solution, as most of these are one click installs, and simple to configure using a YAML file (or similar).
SaaS can also reduce the complexity of managing an exotic build farm if you are delivering to multiple operating systems (Windows, MacOS and Linux). A common combination used by Rust developers is to use Travis CI for Linux and MacOS and Appveyor for Windows when building and packaging software.
However, the upfront investment in infrastructure, and other set up required with a self-hosted solution, will be netted out over a number of projects, and will allow you flexibility in the long term as you are free to add features provided from community plugins and extensions. This is flexibility you just don’t get with a SaaS solution, where you are tied to their feature set and development cycle of adding new features.
Note that the self-hosted route is only feasible if you have a dedicated Ops team, as the chances are that if your CD goes down, your CI will be down too (nearly all self-hosted solution provide CI/CD as an all-in-one package). If both are down then your developers can’t release features.
Having discussed the recommended features (and pitfalls) of both options, below is a selection of solutions that provide said features, which the market currently offers:
Self hosted
Whilst technically a Continuous Integration platform, with the addition of the build pipeline plugin it is easily configured to be a complete Continuous Integration and Continuous Delivery solution.
We have been using it for a couple of years and it is still our goto tool for self-hosting and combined with AWS CodeBuild can allow you to dynamically scale your workers to meet with sudden demand in builds.
– Go
Go is a Continuous Delivery platform written and maintained by the folks at ThoughtWorks, who literally wrote the book on Continuous Delivery, so as you can imagine Go is based on a lot of the principles outlined in it. Like Jenkins (with the build pipeline plugins) it will perform both Continuous Integration and Continuous Delivery.
The newest option in the list – Spinnaker – differs from the previous two as it is only a Continuous Delivery platform. Spinnaker will take a deployable asset (e.g. a Docker image) and deploy it out though the pipeline steps, but only once it has received trigger from a separate CI platform like Jenkins.
New players for Self-hosted
GitLab aims to provide seamless integration between self-hosted and SaaS. With multiple ways to deploy your own CI/CD instance. The added bonus of using GitLab is that you can buy support.
We have used this package microservices as Helm charts (Helm is Kubernetes’ package manager) to be deployed to the Kubernetes cluster. And yes we hosted our GitLab in our cluster.
SaaS
Cloudbees is Jenkins in the cloud. Cloudbees uses a Workflow plugin – which you could implement on your self-hosted Jenkins instance – to add Continuous Delivery functionality. So if you like your self-hosted Jenkins but no longer want to maintain the infrastructure, then this could be an option for you.
New players for SaaS
There’s been a massive growth in this area with cloud independent solutions such as Travis CI, Circle CI.
On the flip side, Microsoft’s Azure Pipeline has strong integration with their cloud offering Azure.
Travis CI is a hosted, distributed continuous integration service used to build and test software projects hosted on GitHub. Open source projects may be tested for free via travis-ci.org, while private projects can be tested at travis-ci.com on a fee basis. They are mostly famous as the go to CI for open source projects.
Circle CI is a platform for software teams looking to rapidly build quality projects, at scale. Their intelligent continuous integration and delivery tools are both simple and powerful. Circle CI allows for a connected development ecosystem where every team member is empowered to make technology decisions. This is our go-to solution within Made Tech unless we’re required to use our customer’s own CI.
Summary
So while the landscape has changed in the last two years, the new features we have seen have made building that all-important pipeline ergonomic and no longer the proprietary domain of the Ops team.
We don’t think it’s possible to ever be definitive and say this is the platform you should be using, or that is the correct solution for you to choose. Different teams will have different requirements for their Continuous Delivery tooling.
The trade-off between self-hosted and SaaS providers remains relatively unchanged. Although perhaps self-hosted has become easier to provision and scale.
If you deliver a large number of client projects, a self-hosted solution that can be tailored to your needs will most likely be a better fit.
On the flip side of the coin, if you are maintaining a single product, a SaaS solution will most likely be your best bet, as you won’t have to worry about the additional infrastructure.
Read more on continuous delivery.
About the Author
Reliability Engineer at Smartwyre
