There are use cases where you want to deploy something straightforward, just by pushing your changes to a git repository, e.g. an update of an internal tool or a typo in a blog post.
For web applications, Heroku has such a workflow. You configure a Heroku remote repository, push to its masterbranch, and Heroku’s after-push hook takes care to roll out the new version of your application.
For hosting of static pages (or simple blogs like this one), GitHub Pages provide the same approach. If you push the content of your page organized as Jekyll project to a special branch called gh-pages then GitHub Page will compile the templates and host the result.
We wanted to have the same comfort for AWS OpsWorks. Most of our web applications and internal tools are running on OpsWorks, and at least for the internal tools, the deployment through Capistrano or the AWS Consolehas been too cumbersome.
We’ve proposed a service hook to GitHub which can trigger an application deployment on OpsWorks. And GitHub has integrated it.
As credentials, you need an AWS key pair (access key ID and secret access key) which has the permission to perform the opsworks:CreateDeployment action, e.g.
{
"Statement": [
{
"Effect": "Allow",
"Action": "opsworks:CreateDeployment",
"Resource": "*"
}
]
}
Beyond that, you have to specify the IDs of the OpsWorks stack and the app you want to deploy.
And as last information, you need the branch name the GitHub service hook should be triggered for. Actually, specifying the branch name is redundant, because this information is available in the OpsWorks app configuration. But in order to skip an additional permission for the AWS key pair and to avoid an additional request in the service hook we thought it would be better to explicitly define the branch name in the service hook configuration.
Note: As announced on December 5, 2013 in the AWS Blog, you can also restrict the permissions for that action to specific OpsWorks stacks using the new resource-level permissions.
Photo by Caleb White on Unsplash