.svg)
Continuous Delivery is the wild west of DevOps. No one uses the same definition. Does CD stand for Continuous Delivery, Continuous Deployment, or both...does it even matter? All tools claim to do “CD” to some degree.
A quick search for Continuous Delivery tools will turn back a long list of companies that literally have CI (Continuous Integration) in their name… not CD.
Not to mention successful CD best practices look different at every company. Some companies want to deploy multiple times an hour, and some companies just want to reach monthly releases.
So who should you trust? As the writer of this blog, I hope you trust me. But it’s up to you to decide whether I’m an honest sheriff trying to wrangle an out-of-control market, or if I’m a Harness android trying to confuse you even more.
The term CI/CD can be traced back to the 2000s right when Java, Javascript, and PHP were emerging. Several developers came together to write the agile manifesto, which referenced the need for “continuous improvement” in technological practices. The agile manifesto paved the way for the release of the first CI tool in 2001, but technological limitations of the time kept CD a pipe dream.
Fast forward through ten years of Continuous Integration innovation, and Jenkins emerged as the defacto CI tool. As CI practices became standardized, a few companies began experimenting with Continuous Delivery. The developers started working on CD using the only context they had: CI tools. They wrote custom scripts on top of Jenkins to create full deployment pipelines. Hence, Jenkins became the first CI/CD tool.
Other CI tools picked up on this and soon, every CI tool touted its ability to create Continuous Delivery pipelines. For five years, CI was synonymous with CD, and it was generally accepted that you could manipulate your CI tool to act as a CI/CD solution.
However, companies realized they were spending too much time scripting CD. As all of you know, wherever there are custom scripts, there’s an opportunity for a new solution. This is where CI decoupled from CD and Continuous Delivery tools entered the market.
Continuous Delivery is the process of deploying build artifacts into an environment. An example of an artifact is a docker container, and the environment could be for testing or for production.
Continuous Delivery tools help create pipelines to standardize releases. Fundamentally, pipelines can be broken down into five stages:
Some CD solutions place emphasis on a particular area, but all will have these basic concepts. I suggest doing more research on what CD is and why you should care.
For the purposes of this exercise, we’ve broken down CD solutions into four categories.
Things we looked for in good CD tools: easy installation, intuitive user interface, enterprise-grade features, low maintenance cost, and GitOps functionality. This list is not exhaustive but should give you an overview of the most popular players in the market.
Open-source tooling is attractive for many reasons. Popular projects have hundreds of dedicated engineers bringing diverse experiences to a world-class product. Not to mention there’s no sticker price.
The downside of open-source is the level of expertise needed to build and maintain the solution. The maintenance effort can often outbalance the “free” nature of the products. Open-source CD tools aren’t optimized for large enterprises with granular security control needs. That being said, smaller shops might find open-source to be an attractive solution.
Argo CD is the cream of the open-source crop. This feature-rich solution automates Kubernetes deployments using GitOps technology and supports a wide variety of config management tools, SSO integrations, and webhook integrations. It reduces administration toil by making application definitions, configurations, and environments declarative and version-controlled. Argo CD’s stated goal is to make application deployments automated, auditable, and easy to understand. It boasts 5k stars on GitHub.
Like all open-source tools, you’ll want to consider the maintenance effort and lack of governance, but overall this is a solid option to deploy code.
Check out our comparison of Argo CD vs Harness to see how we stack up.
GoCD is an open-source “middle child.” The solution is sponsored by ThoughtWorks and has plenty of features like pipelines as code, native Kubernetes integrations, elastic agents, JSON and YAML support, and a modern interface. There’s a solid amount of plugins available on the market, which helps it fit in with your current tool stack.
Unfortunately, it’s a noticeably newer tool that lacks advanced features found in more tenured solutions. There’s quite a bit of potential for improvement here, but at the moment your effort would be better spent somewhere else.
Spinnaker is an open-source solution brought to you by Netflix. There are currently 300 open Spinnaker issues on GitHub.
Spinnaker’s major issue is setup and maintenance effort. On average, it takes Spinnaker users 6-8 months to stand up a pipeline, and by that point, enough engineering resources have been spent to justify the purchase of a different tool. Armory will set up Spinnaker pipelines for a price, but we don’t see the point in that when you have better solutions available for your team.
Check out our comparison of Spinnaker vs Harness to see how we stack up.
Software delivery encompasses Continuous Integration, Continuous Delivery, cloud cost management, feature management, etc. Software delivery platforms decided to provide an end-to-end platform that makes software delivery a one-stop-shop.
Each company has approached this in a different way, and therefore, each company has had varying results.
Harness is a modern CI/CD platform that offers Continuous Integration, Continuous Deployment, Cloud Cost Management, Continuous Verification, and Continuous Features. Harness was founded on Continuous Delivery roots and that still remains one of the company’s cutting-edge products. It leads the pack when it comes to governance with fine-grained RBAC, full audit trails, and proprietary integrated secrets. It’s also worthy to note the incredibly easy installation, which reduces time to value considerably.
The great thing about Harness is its à la carte model. Teams are free to pick Harness modules without purchasing the entire platform. Every Harness product is developed to be standalone in quality and functionality.
Request a demo of our continuous delivery platform today.
GitLab offers a thorough software delivery platform that includes a solid Continuous Delivery tool. All the CD fundamentals exist here, but the tool lacks advanced governance features such as automatic verification, and automatic rollbacks.
The hardest part about using GitLab is its all-or-nothing model. If you want to use any of the GitLab tools, you need to use all the GitLab tools. So if you work in an opinionated tooling organization, you’ll have to convince them to leave behind some of the tools they already use. Our advice for GitLab? Stick to Git.
Check out our comparison of GitLab vs Harness to see how we stack up.
Digital.ai attempts to be a DevOps swiss army knife. Instead, it resembles a butter knife. The company acquired XebiaLabs in 2020 in an apparent attempt to provide Continuous Delivery, but it struggles to keep up with a modern Kubernetes world.
A quick glance at the product section of their website will show you the breadth of their offerings. We recommend going with a platform that emphasizes software delivery specifically.
Check out our comparison of Digital.ai vs Harness to see how we stack up.
Is it any surprise that the three biggest tech companies in the world have solutions for Continuous Delivery? Amazon, Google, and Microsoft each created their own flavor of CI/CD. Something to note is these tools are optimized to work with their corresponding cloud environment. Therefore, these tools are a viable option for organizations running a single cloud environment.
Azure DevOps includes CI/CD pipelines (Azure Pipelines) as well as several other DevOps modules. As expected from Microsoft, Azure DevOps offers fine-grained RBAC and audit trails, making it a smart solution for companies in highly-regulated industries. Azure DevOps also facilitates deployment verification and failure rollback.
Azure DevOps is not strictly limited to Azure environments. This is a tool that you can use across your application stack.
Check out our comparison of Azure DevOps vs Harness to see how we stack up.
Cloud Build, Google Cloud’s CI/CD platform, was named a Leader in The Forrester Wave™: Cloud-Native Continuous Integration Tools, Q3 2019, receiving top scores in the current offering and strategy categories. This CI/CD platform provides standard pipeline features and works well with a modern tool stack.
Honestly, this tool is solid. But it lacks the intuitive design of Azure DevOps. This is still a solid deployment option if you’re on GCP.
CodeBuild is a fully-managed CI/CD tool. It primarily focuses on Continuous Integration, but does offer some basic deployment strategies. CodeBuild exclusively works on AWS environments, making it a no-go for other cloud users.
Amazon’s deployment tool is confusing to set up and manage. Save yourself some time and choose something else.
CD is a new buzzword, and everyone wants in on the action. Unfortunately, this is making it harder to distinguish between CI tools and CD tools. The reality is most CI tools can be extended to CD, but that involves custom scripting, script maintenance, and a less than ideal end solution. We think these CI tools deserve respect for their integration capability. But we also think CI and CD are separate disciplines that have different value propositions.
CircleCI was built for speed and scalability. Build configurations are stored in your application repo as YAML, making it easier to track changes and contribute to your testing process. The Orb system allows you to extend pipelines using third-party functionality with minimal effort. These features create a standardizable CI solution that can easily be adopted. CircleCI definitely rates as one of the better CI tools currently available.
Check out our comparison of CircleCI vs Drone to see how we stack up.
Travis CI was the first CI-as-a-service solution. It was designed for open-source projects: testing them is, and always will be, free - the creators of Travis CI offered this as a way to give back to the community. Additionally, the tool offers a streamlined experience that is easy to set up and use. Configurations are created using YAML. Travis CI lacks many of the enterprise-grade features of other CI tools (think: security and governance), but that, in turn, means it requires little effort to maintain.
Check out our comparison of Travis CI vs Drone to see how we stack up.
Jenkins is old. It was created in a different technological decade and built to solve Continuous Integration. I want to give credit where credit is due. Jenkins out-competed Bamboo (by Atlassian), TeamCity (by Jetbrains), and other CI tools of the early 2010s to become the industry standard DevOps solution. But industry standards have evolved. Any solution that requires dedicated hosting servers and 3-5 full-time engineers to manage it will have a hard time standing up to modern tools.
Check out our comparison of Jenkins vs Harness to see how we stack up.
Each category of Continuous Delivery tools could fit a specific need. Open-source tools work well for smaller engineering teams that don’t need robust governance or a new tool bill. Platform solutions help transform the entire software delivery process and are great tools for enterprises concerned with security. Cloud deployment tools are a great option for companies hosted in one cloud. And the CI tools... well, the CI tools are great to build the artifacts deployed by your CD solution.
Continuous Delivery tools work best when existing tools are plugged into new Continuous Delivery pipelines. For instance:
By connecting your code repository (GitHub, Bitbucket, etc.) to your CD pipeline, you can automatically trigger your pipeline every time a new artifact is committed.
By integrating terraform or ansible into your pipeline, you can create an automated infrastructure-as-code process. This basically replaces the functionality of tools like Chef and Puppet.
By integrating APM and Log tools into CD pipelines, platforms like Harness can use machine learning to verify the success of your deployments.
The more of your existing toolset you can integrate into a CD solution, the more sophisticated your pipelines will be.
At the end of the day, your organization will have specific Continuous Delivery needs, and you’ll need to decide which Continuous Delivery tool best solves those problems. Some key questions you should ask before choosing a solution:
There are definitely tools I recommend avoiding for your own personal sanity, but as an employee of Harness, I have an implicit bias towards the Harness software delivery platform. I recommend taking a look at Harness even if it’s just to create a baseline you can compare to other tools. Try it free today.
Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
.svg){kind=small}
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.
.png)
