Jenkins

Jenkins is one of the most widely used CI/CD systems we come across. Despite its long history and large user base, the common consensus is that there are now far better alternatives than Jenkins. Jenkins is a workable solution for clients already invested in it, but we do not consider it a default choice for greenfield work. While plugins can add features such as containerised builds and pipelines definitions as code, these have to be configured carefully to work reliably and it is hard to avoid a cobbled-together feel. Newer tools which have been built with features such as these in mind tend to offer a cleaner and more reliable solution with less effort.

More information

There are over 1500 actively contributed community plugins available to be used with Jenkins, from simple pipeline plugins that enable chaining jobs, to more complex cloud integration plugins:

If there's something you need to accomplish, there's a high chance a plugin already exists for it.

Flexibility

One of the most powerful features of Jenkins over other newer CI/CD tools like Concourse is the ability to specify, via a plugin, which branch to build as an input parameter. This input paramter can be either user-provided, or passed in as an environment variable.

This provides the ability to create a SDLC that truly represents git flow (below) or even more granular feature-based releases.

Shortcomings

Despite being a ready-made solution with a multitude of plugins available to accomplish virtually every task, there are many drawbacks to using Jenkins as a CI/CD solution:

• Jenkins is self-hosted and will actively have to be maintained.
• Jenkins is not a lightweight solution and there is a cost (both in terms of infrastructure and of requisite knowledge) to implementing and maintaining it.
• Jenkins is a well-known attack vector for organisations. As such, we strongly advise against placing Jenkins in a public subnet accessible over the internet, even if OIDC and user/accounts and groups are implemented. Jenkins should instead be placed in a private IP-restricted subnet, in order to reduce your attack surface.
• When using many plugins it is recommended that you make Jenkins backups, and vet each plugin you decide to integrate with your instance of Jenkins.
• Most CI solutions sit "in scope" of your business secrets (in that they have access to those secrets in order to deploy your application). It is therefore good practice to consider your Jenkins security in the same way you would your application security.