I haven't really looked closely at Drone yet, but you might also be interested in Strider. http://stridercd.com/
One of the things I like is that it's dead simple to get running on Heroku. Language support is a little weak (Python, Ruby, node.js), but we're working on that.
Another nice feature that's currently lacking which it looks like Drone does well is the ability to provision external services (e.g. DB servers) for tests.
More specifically, you currently can't run untrusted code as root in a linux namespace, which is the default backend for Docker. There is work underway to improve the situation in 3 ways:
1) in Docker, to support backends other than lxc, including vm-mapping and openvz which have a better security track record.
2) In Linux, to further harden linux namespaces upstream so that they can safely be used to execute untrusted code as root [1]
3) in ops best practices, to combine linux namespaces with additional security measures (selinux, apparmor, clustering to deploy mutually untrusted containers on different docker hosts, etc).
[1] a big focus of the namespacing effort us user namespaces which makes a container "think" it runs as root when in fact it doesn't. User namespaces work great but haven't been around long enough to be vetted. Beyond that, namespaces are pretty robust and feature-complete already. What's left is to go through the process of auditing, testing and generally allowing it to stand the test of time and scrutiny. Eventually ops and security engineers will warm up to it and it will graduate to "production-ready", the way Zones, Jails and OpenVZ did before it. It's only a matter of time.
So I can run this locally, ensure my test system is dialed in, then scale/automate it with the hosted service? If that's true, it certainly beats having to guess what my test system is actually doing remotely and would definitely help bring some alignment between my prod/test infrastructure.
yes! there is a CLI that let's your run your builds locally, on your laptop. Navigate to the root directory of your repository and run `drone -v build .`
you need Docker installed and the .drone.yml file in the root. it's a great way to test locally without having to push to the CI server. As an added bonus, you could even setup a pre-commit hook
The workflow is pretty basic right now, however, we plan on adding matrix and parallel builds in the near future. Could you elaborate a bit more on your workflow? I definitely want to make sure Drone supports more than just simple use cases.
From my experience with Jenkins, as a build/deployment/release engineer the past 6 years, you probably want to:
- chain jobs - needed for larger projects; ideally this should even allow composing jobs to have nice, modular jobs which can be launched standalone or chained
- some kind of powerful templating system - needed for reducing configuration duplication; ideally this would keep track of all the "children" in case of updates
- you also probably need enterprisey features later on, like SSO using AD/LDAP, fine grained ACLs based on groups, etc
But job chaining and job templating should be higher priorities for the workflows since they affect the overall architecture. Jenkins has been struggling for a while to re-architect to allow this, not entirely successfully.
You also want a plugin system if you don't have one, especially one with dependencies (i.e. the Git plugin can server as a dependency for the Github plugin).
Chaining jobs and parallel ones are both very important. Especially the last one since it saves you a lot of time waiting the tests to complete. Also a big plus is to be able to run certain set of tests only when a specific event is fired eg ran test A when somebody pushes to branch X
1) I don't want to pay for hosted CI
2) Setting up your own CI is a pain in the butt currently
Well done. I'm gonna have a look through this!