|
|
|
@ -0,0 +1,33 @@ |
|
|
|
--- |
|
|
|
title: "Choosing a CI/CD System" |
|
|
|
date: 2020-01-14T17:00:56-06:00 |
|
|
|
draft: false |
|
|
|
tags: |
|
|
|
- "guide" |
|
|
|
- "ci/cd" |
|
|
|
categories: |
|
|
|
- "guide" |
|
|
|
previousPost: "posts/2019-12-25-choosing-a-source-control.md" |
|
|
|
--- |
|
|
|
Once a source control system was decided on and stood up. The next logical step for me was to identify a continuous integration and delivery platform to pair with it. On the home-lab I use the combination of GitLab and the integrated CI/CD system in the suite. With this new environment I wanted to put all the pieces together myself so that the amount of magic was at a minimum. Here are the following CI/CD systems I read about and evaluated. |
|
|
|
|
|
|
|
- [Jenkins](https://jenkins.io/) |
|
|
|
- Jenkins is the one I'm most familiar with, as I use it daily at work. Jenkins is old, but well loved and highly extensible. |
|
|
|
- [Drone](https://drone.io/) |
|
|
|
- Drone seems seems to take a log of cues from CircleCI, TravisCI and the GitLab CI. The configuration pipelines are similar to the pipelines I've written for my local home-lab GitLab instance. In my reading, Drone seems to not handle scaling well, and had some weird limitations (like a repository could only have a single pipeline, meaning all potential pipelines for a repository need to be baked into that one resource). |
|
|
|
- [Concourse](https://concourse-ci.org/) |
|
|
|
- Concourse isn't exactly a CI system, even though it is positioning itself as one. Rather Concourse is a do things system based on the concept that all actions happen in containers and share information between steps via resources. It seems to have playbooks that allow it's usage as a CI, but there's a decent amount of configuration that's needed before it can reach feature parity with the dedicated CI/CD systems. The community is fairly active and there are a decent number of third party resources to interact with external systems. |
|
|
|
|
|
|
|
My criteria was software that I could self host and maintain. The software also had to be something that didn't hide the internals from me and would be flexible enough to work for the foreseeable future. |
|
|
|
|
|
|
|
I have a particular love for Jenkins, and I almost went with it. The Blue Ocean UI is quite beautiful and functional and the jenkinsfile plugin allows for very similar behavior to my existing GitLab setup. However Jenkins is a nightmare for stability and security, and as a one man shop maintaining it could become a full time job. Ultimately Jenkins wasn't going to tick the easily maintainable box. |
|
|
|
|
|
|
|
Drone looked really interesting as the model it used was even more familiar to me. I ran a drone CI for awhile and I enjoyed interacting with it. However I ultimately moved away from Drone as it just wasn't scratching my itch and I sometimes found myself fighting to configure it to do what I wanted. I'm certain that if I had stuck with Drone, that it would've met most of my CI/CD needs and that would be good enough. |
|
|
|
|
|
|
|
Ultimately I settled on Concourse, the "Do Things With Containers" approach really appealed to me and it seemed like a reasonable decision for a piece of infrastructure that might pull double duty within my system. The ability to have multiple pipelines based on a resource also seemed like something that might be advantageous, perhaps breaking the testing, build, publishing and deployment steps into separate pipelines with some sort of semaphore or messaging system between it. As it is, I'm not sure if that's what I'll do, but we'll revisit it in the future after I've been using the setup for a reasonable amount of time. |
|
|
|
|
|
|
|
This is my current Concourse landing page. I've moved a decent number of jobs over to it, ranging from docker image builds through a TypeScript bot for my matrix server. |
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
␀ |
