Here at Mobilise, we have had the opportunity to work with many different CI/CD tools over the years. From client engagements to our own internal tooling. If you have just started your DevOps journey or are looking to move to a new CI/CD tool or even maybe decided to embrace GitOps as your new strategy. Then read on for a break down on some of the newer (and old favourites) of the tools out there.
A firm industry favourite that has been around with the start of the DevOps methodology. Jenkins is an automation server that can be configured to do either continuous integration on its own or taken further to do continuous deployments (or vice versa really).
Like many automation CI/CD tools out there, it’s open-source, and with it being open-source they created a robust and thriving plugin community. Jenkins plugin capabilities are both its biggest strength but also its weakest area. These plugins can help solve many issues that you can face when integrating deployments, testing etc, however, as we at Mobilise have seen, Jenkins can end up with too many plugins becoming an unmanaged monster, which actually hinders the process rather than helping it. Especially from security management and patching process side.
Overall, Jenkins is a feature-rich CI/CD system that enables you great flexibility to create all sorts of pipelines to achieve your DevOps goals. Just have to make sure that you don’t try and use every plugin under the sea to achieve that CI/CD dream and try to use Jenkins in-built functionality.
Drone.IO is one of the newer flavours of CI/CD tooling that is not only Docker and Kubernetes native but also embraces a GitOps methodology. Let us use our previous tool Jenkins as an example. You would normally have automation (DevOps) engineers go into Jenkins and create pipelines for developers to use, in Drone. It works directly with your own repo of choice. Everything you do whether it’s CI or CD is controlled in a .Drone file that is a YAML base instructions file for Drone. Drone will then use the file to rerun what each stage has specified.
This is a great option if you want to continue shifting left and hand over more responsibility to your developers as you can then free up your Ops engineers to focus on other parts without having to focus constantly on all the automation pipelines. Drone being fully cloud-native makes it a big plus if you intend to be completely cloud-based.
Currently, Gitlab is a leader in the cloud-native landscape and is what we use at Mobilise for our own internal tooling. Gitlab has also embraced GitOps and is similar to Drone in that you will have a GitLab YAML file where you will declare your pipeline steps. However, GitLab has some key differences to other GitOps CI/CD tools. One of the key differences is that GitLab is also and somewhat primarily a repo where you can store your source code. This has the added benefit of it being a bit of one-stop-shop for all your code and CI/CD needs.
Another extremely helpful feature (if you don’t happen to have DevOps engineers to hand) to help devs get up and running is that GitLab has what is called ‘AutoDevOps’ (and no, it won’t solve all your DevOps needs but it certainly helps!), which creates the basics that you need for a CI pipeline. Furthermore, if you go up their license tiers you get access to automated security, monitoring and agile tools. Truly making GitLab the ultimate one-stop-shop for most modern concepts that are cloud-native, DevOps and Agile.
Spinnaker is another cloud-native tool that focuses upon continuous delivery of applications, with the focus being around management and deployment. So how does this differ to other tools in its class, and why would you choose a tool that does only CD but not CI.
Let’s focus on what Spinnaker is best at, deploying microservices applications into Kubernetes cluster. With Spinnaker, you have to define the infrastructure that the applications will be deployed into. As when Spinnaker is deploying via the pipelines it checks the health of applications that are using the infrastructure that you defined. With deployments handled you can then focus adding extra tooling around other parts without having to worry about Kubernetes/ container orchestration.
It’s fair to say that if you are planning to use Kubernetes and need a tool to manage your deployments into various cluster stages, then Spinnaker is the tool for you.
In the vein of Cloud Native CD tools, there is a new tool on the block. Flux is currently in CNCF Sandbox incubation so is very much in active development. Does that mean you shouldn’t use it? Absolutely not. It’s still a very good tool at managing deployments in Kubernetes clusters. Let’s get into what it does and why you should think about using it.
Firstly, Flux has fully embraced GitOps. When compared to the other tools on this list, it is more committed to it. Say you wanted to deploy your whole system through Git, Flux will assist you with it! As long as it has declaratively described files in it, Flux can deploy it. The great part about this tool is that when developers come to use it all they need is a normal understanding of git branches, PR’s and merge. As Flux takes care of the rest. That way any changes you make in version control you can rest assured that they will then be correctly reflected and synced up.
This tool is worth keeping an eye on as it goes through CNCF incubation to graduation.
There are more tools out there
This isn’t a full list of all the tools out there. Some of the excellent tooling that Mobilise has had a lot of use.
Here are some other tools you can use:
Honourable mention: GitHub, while it is the most famous and recognisable source code storage of all have also introduced their own CI/CD features. GitHub Actions, allowing anyone with private or public repos to deploy and test their code without needing to use any of the above tools. It will be interesting to see how this evolves over the coming months.
Hopefully, you now have a good idea of the range of tools out there. With this blog helping to narrow it down. Remember to always try multiple tools as part of your discovery exercise. Find the one that meets your integration and deployment needs.