In my first post about GitHub Enterprise backup, I outlined why the open source ghe-backup project was started: To provide GitHub Enterprise Backups based on AWS with the STUPS platform. The following post will focus on the Continuous Delivery of ghe-backup instances on AWS.

Why do we care about Continuous Delivery of ghe-backups? Well, there are regular changes in Taupage and ghe-backups have to run an up-to-date version of Taupage. Every important fix or change, as well as the recurring expiration of Taupage, requires a new deployment of ghe-backup. Hence, a Continuous Delivery pipeline makes perfect sense.

In my role as Delivery Lead, my aim is to use the services provided by the teams that I’m accountable for. One of these teams provides several managed Jenkins automation servers on AWS for Zalando Tech internal customers. Naturally, I went for one of these setups to implement a Continuous Delivery pipeline.

The current delivery pipeline looks like this:

The pipeline view is based on the Jenkins Build Pipeline Plugin. This will most likely be moved to Jenkins 2.0 once production ready.

Not every pipeline running requires a deployment. That's why the pipeline contains four manually triggered jobs (highlighted above in blue). These are divided into two branches, one per AWS account to deploy to.

Successful deployments to the two separate AWS accounts results in the view below:

Basically, there are three common jobs for every pipeline run:

• Testing
• Docker image creation
• Docker image push

Branching the pipeline is necessary since deployments are AWS-account specific. Different AWS accounts also require different senza yaml configuration files. This gist provides a default sample senza yaml for ghe-backup.

The actual deployment happens using Lizzy. Lizzy, as well as Jenkins based on AWS, are both developed under teams that I’m responsible for.

Lizzy is a HTTPS wrapper around senza (a command line deployment tool to create and execute AWS CloudFormation templates) that allows across AWS deployments. Whenever the Lizzy agent is rolled out in an AWS account, the AWS account responsible defines which permissions the Lizzy agent gets. This way, you can control what permission deployments shouldn’t be used within your AWS account.

The last deployment step of the pipeline above calls Lizzy in the AWS account to deploy to. Lizzy starts the deployment and reports back to the deployment job about its success (hopefully) or failures.

With the Continuous Delivery pipeline described above, we are now able to deploy any change within minutes – be it in ghe-backup code, in Taupage across AWS accounts, or to both AWS accounts that run GitHub Enterprise backups. If required, we could even configure the pipeline to deploy automatically, without us intervening.

If you have any further questions about the pipeline, I’d be happy to answer them!