Even though I use Jenkins as CI/CD every day — I’m not stopping looking to its competitors. That’s why I was experimenting with Brigade.sh a few weeks ago, that’s why I was experimenting with Drone.io yesterday!
Drone is a Continuous Delivery platform that helps your organization optimize and automate software delivery.
High level concept
Unlike Jenkins, Drone.io is container native solution, this means that every single step is executed in the Docker container. This is similar to the concept used in Brigade.sh or Concourse.
Even the plugins are Docker containers, it means that you can write your very own plugin (in any language you want), push it to the Dockerhub and profit.
Personally, I think Container native solutions are the future. It’s just so much cleaner than scripted pipelines working on top of shared workspace!
As I’ve mentioned before, Drone.io is container native solution. So it would be a shame if the installation was not container based, right? Everything is documented here, this is single-machine scenario with Github integration which will be absolutely sufficient for basic user testing.
You basically just need to register a new application in your Github account and start a Docker container with the certain parameters. And that’s it. Translated to numbers, in the cloud era when you don’t have to hassle with the installation of computing resource you can build Drone.io node in less than 5 minutes!
- Create Virtual Machine and record its public IP address
- Create a DNS record (required for Oauth callbacks)
- Install Doker CE
- Register a new application in your GitHub account
- Run the Drone.io container according to documentation
docker run \
In the main screen of Drone.io you have to enable your repository first.
It will open a repository configuration menu which is almost as same as minimalist as the main screen.
There’s really nothing we have to think about, everything important will be written in .drone.yml file! Let’s write out first pipeline.
I have to repeat myself, everything in Drone.io is just container so the pipeline syntax reflects this fact — almost every letter there is related to the container specification. Neat.
The basic Hello World example
- name: hello
- echo Hello World!
becomes this when we push to the master branch
Each pipeline step can be configured to be triggered only by certain events or in certain branches. You can find documentation for the whole topic here. This is typically useful for pull request events when you want to run some tests without building the final image etc.
- name: test
- npm install
- npm run test
- pull_request- name: build-docker-image
- echo Building image
So in this example, every event will trigger “test” step but “build-docker-image” will be triggered only by pushing to master, stage or development. Let’s test it with pull request.
First we have to open a new PR
Which will produce following output
See? Pipeline step “build-docker-image” was not triggered. Now let’s merge these branches.
Bingo! Our dummy “build-docker-image” step is triggered only by push events.
Drone.io also supports secrets management, it means that you can keep your API keys out from the version control system. You just need to create a new secret in the repository settings
and refer it in the pipeline like this
- name: build
Drone.io should also support Vault integration but I’ve not tested it yet. But if this is true — it’s killing feature 😉
Sometimes you don’t want to deploy new build automatically, you know, things can get messy. For those cases, Drone.io introduces a special event: promotion. This event has to be triggered from the Drone CLI (available for all major platforms) and the timeline of usage is following:
- push event with number XY
- build has finished successfully
- promotion of build number XY to the given environment
As I said, promotion is just another event so you can add conditions for this particular event. See the example.
drone build promote vranystepan/drone-hello-world 48 production
- name: deploy-production
- echo deploy-production!
I think Drone.io is the very competitive product that can cover almost every CI/CD use case. There might be some concerns from Jenkins users who are used to create complicated scripted pipelines with dozens of plugins but this is the matter for some comparison article (and this is not my goal to do that).
I’m very impressed by the simplicity of the whole product. For the Jenkins user, this is a whole new universe 😀 Can’t wait to test with some real project!
Do you have any tips or comments? Do not hesitate to leave a comment in the discussion!
Edit #1: you can even specify multiple pipelines for different events in the single file!
- name: test
- echo cd works.trigger:
- name: test
- echo ci works.trigger: