deployment-with-github-actions/

[giscus[bot]]

deployment-with-github-actions/

GitHub Actions can be used for Continuous Deployment (CD) - but there are some rough edges. In this post I take you through a deep dive and lift the kimono on Actions.

https://colinsalmcorner.com/deployment-with-github-actions/

[jSherz]

I also lost a fair chunk of time to the Terraform wrapper. An elegant footgun!

[DanyC97]

@colindembovsky much thanks for writing this story, it made me laugh all the way as i've bumped into all this issues for the last 2 weeks just to realise that GHA and the CD in particular are not there yet to be considered for serious (multiple envs scattered across different AWS accounts) real world deployments.

My world is a hybrid of RDS + serverless (lambdas etc) and TF and i have to say that is critical to be able to restart jobs/ stages w/o sending the dev back to PR -> merge -> etc. TF plan is great but sometimes you find out if things works only after TF apply and and when things go bad .. you need more TF subcommands and so catch 22.

• massive jobs with massive steps in single workflow
• unable to restart the jobs
• if you need debugging options (cause things timeouts/ fails in the cloud) you end up with crazy amount of workflow_dispatch flows.
• not to mention that there is no DRY principle in GHA
• the UI .... if you have tons of workflow runs per day, you might not easily know which jobs are waiting to be approved unless you hop onto each of them ..maybe on the roadmap ;)

[jontyq]

Hi Colin, a year has passed and GHA now has templates - how would you assess maturity of GHA for deployment now (particularly for Terraform) ?

[colindembovsky]

Hi @jontyq - GitHub Actions now has reusable workflows, which are somewhat like templates, but not exactly. One of the main limitations is the primitives - you can only pass number, string and boolean args to a reusable workflow. This makes some complex templating really hard to accomplish.

Having said that, you could quite easily make a reusable workflow to execute Terraform commands. This will work if you always use the same commands - so specifying arg overrides would have to be handled with files rather than passing in via the command. If you have standardized commands/file naming conventions, you could create an easy-to-use reusable workflow.

In short, you can definitely use reusable workflows and GHA to deploy Terraform - the more standardized the naming conventions are, the more generic you can make the workflow.

I've created a workflow that can create a Terraform plan, uploads it as an artifact and outputs the summary as a Step Summary. Then another job that download the plan and apply it. I include linting as well - you could also incorporate Infra-as-code testing using checkov or other tools.