This article talks about the deployment to Azure Infrastructure with GitHub Actions.

The benefits of using IaC are best realized when the CI/CD pipelines deploy it in an automated and repeatable fashion.  A structured solution for deployment is required to meet the needs of automation and the benefits include the following: 1. Declarative form for defining and deploying, versioning and review. IaC also prevents any drift in the configuration. 2. Consistency in following an IaC process that ensures the whole organization follows a standard well-established method to deploy the infrastructure 3. Security for hardening and approving cloud operations and to meet internal standards. 4. Self-service for the teams to be empowered to deploy their own infrastructure. And 5. Improved productivity by provisioning new environments and leveraging standard templates.

The control and data plane are separate in this solution.  The data flow involves creating a new branch and checking in the needed IaC modifications. A pull request is created to merge the changes into the environment. A GitHub actions workflow is triggered to ensure the code is well-formatted, internally consistent and produces secure infrastructure. A terraform plan what-if analysis can be run to preview the changes. Once this is reviewed it can be merged into the main branch. Another GitHub actions workflow will trigger from the main branch and apply the changes. A regularly scheduled workflow will also run to look for any configuration drift in the environment and create a new issue if changes are detected.

GitHub environments and secrets store the Azure Identity information and set up an approval process for deployments. For example, a production environment will have a protection rule and add any required approvers needed to sign off on the production deployments. It can also limit the environment into the main branch. An Azure application identity with read/write permissions to the Azure subscription is required. The GitHub secrets usually include the client id, client secret, subscription id and tenant id. The state file location will be needed to persist the state between different runs of the workflow.  This location will be saved to the IaC backend configuration block. Once the environment and the identity are created, a reader and data access permission set will be required for the storage account where the state resides. A set of read/write identity and read-only identities will be helpful to separate accesses on environment and activity basis.

Two forms of validations are popular with infrastructure deployments, and these are unit-tests and What-if deployments. The unit-tests on the infrastructure code is possible with the help of options from the compiler, linter and formatter that catches errors with syntax, declarations and typos.  For example, terraform fmt and validate are commonly used options. There is also an open-source static code analysis tool called Chekov that can be run to detect security and compliance issues. Results from the tests can also be uploaded to GitHub. The what-if stage of the workflow, also called the dry run is used to understand the impact of the IaC changes. Typically, this is triggered by a push to the main branch. It will be followed by the deployment stage that will be accompanied by a manual approval. The drift detection workflow, if present, can run periodically and independently of the changes contributed to the IaC.