This article will assess the advantages and disadvantages of implementing dedicated CI/CD Infrastructure vs CI/CD as a Service, to understand whether Jenkins is still a viable CI/CD option.
To evaluate the above, it is imperative that we first understand the following
- What is CI/CD
- What is Dedicated CI/CD Infrastructure / CI/CD as a service
What is CI/CD?
Imagine you have a team of Java developers that continuously push code changes to a repository; a CI/CD tool would pick up those changes and build out the solution. This is known as continuous Integration (CI) – the practice of automating the integration of code changes from multiple contributors into a single software project. Those changes would be released into development phased environments, known as continuous Delivery/ Deployment (CD).
What is Dedicated CI/CD infrastructure vs CI/CD-as-a-Service?
Now that we understand what CI/CD is, how is this tool provided?
One way CI/CD could be offered is through installing a CI/CD tool such as Jenkins onto your own machine, whether this is your own physical server or a virtual machine in the cloud. Jenkins is an automation tool written in Java with plugins built for Continuous Integration purposes. Jenkins is used to continuously build and test software projects, making it easier for developers to integrate changes to the project and to make it easier for users to obtain a fresh build.
Another way you could utilise CI/CD is through the concept of “CI/CD-as-a-Service”. Instead of owning a dedicated machine to host, for example, Jenkins, you could adopt a similar service offered online. A great example of such a tool would be Azure DevOps. Azure DevOps is a Software- (SaaS) platform from Microsoft that provides an end-to-end DevOps toolchain for developing and deploying software. This includes Kanban boards for project management, wiki for collaborative communication, testing tools for your quality assurance team members as well as the repository and pipeline automations.
Jenkins CI/CD instances Vs CI/CD-as-a-Service
Let us now evaluate whether it is worth using Jenkins instances in contrast to CI/CD-as-a-Service such as Azure DevOps.
Nothing in life comes for free
Jenkins is an open-source tool, which means it is free; however, you would need to host Jenkins on a server, which costs money. On the other hand, Azure DevOps is free for open-source projects and small projects, but only for up to five users. For larger teams, VisualStudio and MSDN members who bring their own licence, the costs range from $30 per month (10 users) to $6,150 per month (1,000 users). Therefore, if you have a small team with a small project or invite MSDN members to contribute, then Azure DevOps might be your answer.
Since Jenkins would be held upon an instance, you would need to be responsible for maintaining the machine. In other words, if your team is in the middle of running a deployment to production and the machine hosting Jenkins was to go down, then you would need to have mechanisms in place to mitigate deployments being blocked. CI/CD-as-a-Service, on the other hand, is maintained by the provider; as a consequence, the chances of its service going down is rare as they would have many procedures in place to ensure high availability.
The performance for running Jenkins on a dedicated machine really depends on the machine specs and the connectivity. Sometimes the interface may lag, and you may find yourself waiting to click on the build button. Jenkins slaves (workers) are also deployed on owned infrastructure, and there is a cost associated. Azure DevOps, on the other hand (as a service), runs on scaling infrastructure and therefore does not have this issue. It should be noted that the ‘workers’ performing the build are often separate systems, and so the spec of these instances is important. Workers have the advantage of being able to use multiple operating systems to develop and build automation; they can also be placed within internal networks that cannot be directly accessed by Azure DevOps or Jenkins, thus, maintaining security boundaries. Azure DevOps has the distinct advantage of having a massive pool of public workers to utilise for free.
Configure Pipelines Scripts
Since Azure DevOps allows easy connection to other tools such as Terraform, ARM or .NET, it provides simple mechanisms to configure pipelines as code without having to type a word of YAML. There is a massive online marketplace providing thousands of plugins and tools for this purpose. For instance, you could configure a YAML file to deploy your Terraform code automatically by just accessing the Azure DevOps GUI to auto-populate code such as run Terraform init, plan and apply. Jenkins UI is very outdated; therefore, you would not be able to perform such a task, and this task is great if you are new to writing pipelines using code and just want to get the automation going.
Unlike Jenkins, Azure DevOps provides granular analytics at the end of each run, with parameters like rate and duration. This feature is helpful to identify ways to increase the performance of deployment runs. It is also beneficial when creating project deployment run books, as this would provide more accurate predictions for deploying infrastructure to production within a time window.
Jenkins is still an option most clients go for, and it depends on your project requirements and team size. If you want to manage your builds and deployments privately within your physical infrastructure, Jenkins is the way to go. If you have a small team and you want to start building and deploying your code quickly, then Azure DevOps is a tool to adopt.