In early 2020, we recommended the adoption of GitHub Actions for contemporary deployments. Absent a mature integration with CodeDeploy, we recommended apps deployed on legacy infrastructure remain on Travis CI.
As of November, Travis CI throttled compute resources to open source builds, greatly increasing build times from minutes to hours or longer for our public repositories.
As such, we evaluated alternatives based in GitHub Actions and now recommend that apps deployed on legacy AWS EC2 architecture are migrated to GitHub Actions, with deployments via the webfactory/create-aws-codedeploy-deployment action.
In our initial evaluation, the big deal breaker was that we would not be able to integrate with CodeDeploy without writing custom code. As this was a huge pain point for past deployment strategies, I did not want to reintroduce it here, so I did not consider a roll-your-own solution, e.g., use of the AWS CLI for deployment.
Since our initial evaluation, at least two CodeDeploy integrations have emerged:
Per one of the maintainers, the Webfactory action was built for internal purposes, but it provides useful documentation and is written in clear JavaScript code, making it easy to evaluate and pilot for our own purposes.
The BYU integration may be generalizable, but it appears from the README to be mostly purpose built, with uncertain maintenance futures:
Hopefully this is useful to others at BYU. Feel free to ask me some questions about it, but I make no promises about being able to commit time to support it.
We also piloted an alternative to direct integration with CodeDeploy: pushing code bundles to S3 and configuring CodeDeploy to build from the relevant S3 bucket.
This is a clever solution involving more configuration than custom code, an advantage. However, it implicates a second AWS service, S3, and the link between S3 and CodeDeploy is invisible, making migration and maintenance somewhat less straightforward than a dropin replacement for deployments via CI.
If we were routinely deploying new apps on AWS infrastructure, this might be acceptable. The reality is that this change mostly implicates legacy apps with limited maintenance budgets, so ease of use is a top priority.
With all of that said, if for any reason we decide to abandon direct integration with CodeDeploy, the S3 -> CodeDeploy pattern could be a reasonable fallback.
I piloted webfactory/create-aws-codedeploy-deployment in the Metro project suite:
Advantages of GitHub Actions for legacy apps:
- Overall build time reduced from hours to minutes versus Travis CI
- Consistent deployment practices for apps, regardless of the infrastructure they're deployed on
- The Webfactory integration can create deployment groups on the fly, enabling a behavior similar to Heroku review apps (if we wanted it)
Disadvantages of GitHub Actions for legacy apps:
- The Webfactory integration does not support deployments from tags, so we have to switch to deployments from a branch
Webfactory is a software development company in Germany. As with any free and open-source software, there is always the risk that the maintainers could choose to shelve or even sunset the code. Some positive signs on this front:
- The current iteration of the integration works for our purposes. This will only ever not be the case if AWS makes material changes to its API.
- When we did encounter a problem, the maintainer was responsive and friendly, offered a stopgap solution, and ultimately cut a new release with a fix.
- Per the maintainer, the integration was developed for internal use. While it's still young and relatively untested, they have plans to adopt it more broadly, a good thing for mid- to long-term maintenance.
If there is ever a need to switch away from this pattern, removing it is as simple as deleting a few lines in a GitHub workflow.