LeeroyCI – taking down production with automatic deploys since last week
Let me give you a quick update about a new feature that made it to Leeroys master branch. Deployment. You can now specify a script that will run after a build for a branch was successful. Initially I planned to focus on deployment when working on version 2 or a late 1.x release – for me this is a scary feature and I would have preferred to focus on testing right now. But at FlightCar we decided we want to start leveraging continuous deployment and so I began to work it.
Why did I say this is a scary feature? Leeroy is not only used by me. Some people already trust it with running tests for their start-up or hobby projects. Hopefully more people will start using Leeroy and some of them eventually decide to let Leeroy automatically deploy branches. Deployment is working as everything else, by calling an external script or program. So, in the end, if a deploy is not working, eventually taking down production, you could blame the person who wrote the test or deployment script. In my opinion it is not that easy.
I see it as my responsibility to make deploying through Leeroy as secure and convenient as possible. There will be a grace period of likely 30 seconds in which you can cancel a deploy by just clicking on a link. It will involve a lot notifications, in its first incarnation eventually too many. But at the end of the day I want to be sure this feature will, once we hit 1.0, be so rock solid that if a deploy is ever failing or messing up something everyone can easily agree it was not Leeroys fault.
The trick will be to keep things simple. One of the reasons why I started working on Leeroy was that the existing CIs are either complicated or impotent. I want to keep Leeroys simplicity even while offering features like automatically deploying your latest changes. I am satisfied with its current state – or it would not be in master. It is deploying two Django based environments under my watch right now, I use it to build Leeroy branches and upload the binaries to S3 and I am about to configure it for drupan this weekend to publish changes in master to pypi.
Okay, that is enough whining. Give it a try, the configuration is simple and if you are on Heroku or Elastic Beanstalk a deployment script can look as trivial as this
#! /bin/bash cd /home/ec2-user/test-deploy git fetch get reset --hard origin/master git aws.push
So not much magic involved here. Do not worry about deploying broken code, it will only deploy if all tests pass.
Some things you will see happening shortly:
- custom templates (this is already in testing)
- simplified notification system (eventually with custom notifications)
- more notifications (deployment announcements e.x.)
And after I got those done the next two bigs steps are
- admin interface (including user support)
- notifications about successful deploys
This is what I am planning to get done this year. Ignoring the GitLab and BitBucket integration for a moment (this does not mean it will not be done), the roadmap for 1.0 looks pretty good and suggests a 1.0 beta between Christmas and New Year.