Which CI/CD tool will work best for you?

How your tool is hosted might make a big difference to your organisation. In some cases, it will be mandatory – regulations or company policy might stipulate tools have to be self-hosted behind a private firewall. If that sounds like your business, you’re going to have fewer options and need a dedicated team to maintain the infrastructure. 

There are advantages to both managing your own instance and cloud-based solutions. With cloud, which is the preferred hosting option for Atlassian and their tools (like Bitbucket pipelines and Jira), onboarding, maintenance, security, and continuous support will be taken care of. And you can make the most of cloud platforms too, like AWS or Microsoft Azure which you can use to run Bamboo server, or your cloudbees Jenkins deployment.

Some on-prem options, such as GitLab (which also has an SaaS version too), can be managed on your own infrastructure or in the cloud – while Atlassian’s CI tool Bamboo is only available in a self-managed on-prem configuration. With on-prem options, while you’ll have to manage and maintain them yourself, you’ll have more flexibility when it comes to expansion and customisation, and costs could be lower. Some sophisticated hybrid solutions give you the best of both worlds – they can be run in your own Data Center, utilising the cloud when necessary to accommodate a variable load.

It’s hard to argue with the benefits of open-source software (OSS), such as Jenkins, Circle CI, and GitLab. For one, it’s free. But beyond that, it offers an excellent way for developers to learn new skills and collaborate with a much wider community. That means harnessing the power of a hive mind at zero cost to your organisation. Plus, with complete code transparency, you know exactly what you’re getting and can make alterations to suit. 

That said, the total cost of ownership could be much higher than you think, given that you need a heck of a lot of engineering resources to configure, maintain, and modify this type of software, and you’ll need to run it on-prem. There’s a chance the vendor might abandon the project or you won’t have the support you need. Proprietary models, on the other hand, offer commercial support as part of the package. So you’ll have advice on tap from product experts who’ve resolved common issues many times over. 

OSS comes with inherent quality and security risks, opening your organisation up to potential cyberattacks and breaches. To give you an idea of the impact, according to Forrester’s The State Of Application Security 2021 report, the percentage of code base that is open source has almost doubled in five years – from 36 percent in 2015 to 70 percent in 2019. Now, almost 99 percent of audited codebases contain some amount of open source. There are security solutions for OSS packages though, such as Sonatype Nexus, a detection system that stops known and unknown open-source risk from being downloaded into repositories. 

To ensure security is not a serious issue, you’ll need to know if it meets your organisation’s quality standards and if you have the infrastructure in place to handle any issues that arise, and what those might be. You’ll also want to understand where responsibility lies for securing OSS dependencies and who will manage any risks going forward.

Choosing a complete DevOps platform like GitLab, for example, will save you money, offer better traceability, and reduce complexity. However, it’s also worth asking if one tool is the right solution or if you’d be better off sticking with a set of tools, such as cloudbees Jenkins for CI and Bitbucket for SCM with a Jira integration. A multi-tool approach has the added bonus of not making your organisation too dependent on a specific service. If support starts to suffer or a tool is discontinued, your business continuity won’t be interrupted.

Whichever approach you choose – one tool or many – standardisation ensures a single toolset is used across the organisation. That means a common platform, practices, and reporting processes. Sure, some initial effort is required, but once you’ve got the system up and running, your team can focus more on enhancing your products and less on the system details involved in delivery.

Integration is a core consideration, unless you’re starting your tool stack from scratch. You don’t want to have to change all your existing DevOps tools just to match one CI/CD solution. Check your CI/CD server works with what you’ve got – most should be able to handle seamless integration out-of-the-box (or with the help of plugins). Atlassian ’s new solution – Open DevOps – for example, integrates other Atlassian tools, like Jira and Bitbucket, with partner products, such as GitLab automatically.

Get up to speed on what tech your teams are already using. Compare tools to see what integration capabilities they have. If you’re unsure about how to integrate or migrate your toolchain, there are experts out there, such as us here at Adaptavist, that can help.

Features and flexibility are paramount to help your teams to thrive. You need the build, test, and deployment process to be adaptable, scalable, and straightforward. Some core features to keep your eyes peeled for include:

Review apps, which automatically spin up dynamic environments for new code even before it's merged.

Canary deployments, minimising the impact of any deployment issues by deploying to a small portion first.

Auto-scaling agents – these help you to scale up and down, saving computer costs during peak usage. 

It might be hard to know which features you need, especially if you’re just getting started. Perhaps the basics are sufficient for now, but as knowledge and awareness grows, you might want more in your toolbelt – code quality tracking, simplified system maintenance, and extra integrations to track bugs, to name a few.

With endless money to spend, we could all have everything we wanted, and then some, but reality looks a little different. Think about your current needs and your expected needs – such as headcount goals, expansion plans, and what products and services you might introduce in the future. Looking at the bigger picture will help you focus on value as well as the price tag.

That said, a big budget is not a prerequisite to CI/CD implementation. What you do need to know, however, is what service plan is suitable for you. Think about how often your team is building per day, concurrent builds, user numbers, and the amount of data retention you require. Keeping the considerations above in mind – weigh up the benefits of ‘free’ open-source offerings against commercial expertise and support, to make sure the total cost of ownership is within your means.

Choosing a CI/CD tool is one of the final steps before implementation can begin, so don’t falter at the final hurdle. Put the effort in to find one that will enable your strategy to succeed, rather than just going with whatever’s popular. 

If you’re still unsure which tool will stack up for your organisation, Adaptavist can help. Our managed services combine the right mix of strategic-led consultancy and technology-led solutions that place people, process, and tools at the heart of your DevOps strategy.