Open Source Continuous Deployment

“Continuous Deployment is simple: just ship your code to customers as often as possible” -Timothy Fitz

Going from code to deployment in the easiest and most pain-free way is the goal.

This mostly includes:

Issue-Tracking System

Version Control

Continuous Integration

Build and Unit Tests

Deployment to Production

Fail-Fast

Services have been written to get the job done, but most are paid and hosted solutions.
Github Enterprise, Jira, Gitlab, Travis-CI, etc…

All great tools for their use, but sometimes it’ best to host the services yourself for no fees. The tools used here are all free and open source.

Step 1. Version Control & Issue Tracking

Gogs is a Github clone written in Go. It has evolved into a respectable application. It features organizations, teams, issue tracking, repository hooks, and way more. Check it out. The project is currently hosted on Github.

And that’s it. Setup a reverse proxy, ssl, and run it in a screen/tmux/nohup for better performance.

Step 2. Continuous Integration

Drone is a Continuous Integration service that utilizes Docker to build and test applications. Pull requests get tested before merging as well. Build status can be emailed, announced in IRC, or sent in other addon chat protocols

It can OAuth logins with Github, Github Enterprise, Gitlab, Bitbucket, Gogs, and other services. So there is no need to register on the server, you authorize Drone access to your account and it will query for all your repositories.

The .drone.yml file has the ability to trigger a deployment at the successful completion of your build.

Add the Drone public ssh key provided in your Account settings to your production server.
Add deploy parameters in the .drone.yml file to ssh in, clone the master branch, and restart services.
More guidance can be found on the Official documentation and some basic scripting

Conclusion

Great!
Now we have an open source, free, and automated environment that will version control, issue track, build, test, and deploy code. This is perfect continuous deployment. Code that breaks will not be deployed, so chances of failure go down greatly. And since we are continuously deploying, no reason to wait a week to push fixes if we do fail.

The code to deployment pipeline should be very fast. In the event of a failure, fixes need to get deployed as quickly as possible. “Set a fixed goal for the total commit-build-deploy process. At IMVU that goal was roughly 10 minutes, at Canvas that goal was 5 minutes.” - Timothy Fitz
Drone’s build & testing using Docker is extremely quick for my python-flask application.