Recently, we have been evaluating Continuous Integration (CI) systems for a variety of projects (both OSS and customer). There are many OSS options to chose from. Because we already use Docker containers for Yocto/OE builds, Concourse and Drone made the short list. Both communities seem responsive and helpful.
Building OE in a container is important, so naturally Drone and Concourse seem like good options as they are focused on containers. Containers make sense for most CI tasks as they allow you to easily control the environment without getting bogged down in setting up the host. Because Concourse does not seem to easily support bind mounting volumes on the host system, we ended up implementing a prototype in Drone. This was improved and merged into the yoedistro master. Ironically, we are not currently building in a container, as the yoedistro CI machine is a 64-core ARM system and we had some problems with the container support. Hopefully we can get containers working again at some point. Since the initial evaluation, Drone has added an exec runner, which allows us to execute a pipeline directly on a machine without a container.
Drone is an excellent fit for most of our projects. There are more capable systems (like Concourse, Jenkins, etc), but the simplicity of Drone is a big advantage in that it will more likely be used by developers. A tool is only useful if it gets used. With Drone, a developer can simply cd to a Git workspace that has a .drone.yml file, and then run drone exec and it will run the entire pipeline locally. Because drone typically does everything in containers, this works fairly well — it does not really matter what the host system is. This is powerful because developers can test the entire pipeline on their local machine before enabling it in the drone server/agents for automated testing/deployment. If there are problems, they can be debugged locally rather than the tedious process of commit, run the pipeline on the server, view the logs, repeat. Solutions that are simple to use make a big difference in productivity.
Below is a quote from a Drone user:
Today we have over 60 engineers interacting with Drone daily, and they really like it, due to its simplicity. We’ve always had a small DevOps team, so we tend to heavily favor solutions that don’t require a lot of maintenance overhead, and Drone fit the bill. Since most developers have at least a basic understanding of Docker, they hardly need any help maintaining their pipelines, and there have been a couple of instances of developers creating their own plugins! This way our team can focus on exciting upgrades to our infrastructure, even as teams regularly update their deployment pipelines and new projects are created every month.
https://blog.drone.io/why-quinto-andar-chose-drone/
Drone makes some interesting trade-offs in that it trades some flexibility for simplicity and developer ease of use. Initially, Concourse was my first choice as it is a more powerful tool, but because it does not support bind mounting host volumes or exec runners, we ended up using Drone. This tool makes sense for many teams because it is more likely to be used by the average developer without having a dedicated CI/Operations team.
This is a trend we are seeing at successful companies where developers are more responsible for everything related to their project, including testing, continuous integration, deployment, and operations. The quote below gives us some insight into how things are done at Amazon:
There is another lesson here: Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.
— Werner Vogels (CTO @ Amazon), https://queue.acm.org/detail.cfm?id=1142065
Drone fits into this model well because it enables developers to become engaged in CI and deployment.
One potential problem with drone is the lack of support for some Git systems like Assembla. One workaround would be to store pipelines in Github/Gitlab/Gitea, etc, and then fetch code from other repos. But it would quickly make sense to add auth/webhook support for whatever Git system is used if it does not already exist.