Getting Started with GitHub and Terraform

The Global Digital Cloud Transformation, of GDCT, is providing the details associated with developing Automated Web App Services on Azure.

This process document outlines the framework for deploying Azure and Google Resources using our modern DevOps framework. Utilizing this framework will accelerate deployments to Azure along with keeping them secure and in compliance with Seagen policies.

This document follows the Developing Automated Web App Services process flow found here

Project Request Process

Define Platform Following these steps will build a secure and compliant foundation and removes all of the complexities of setting up a subscription, authentication, and CI/CD pipeline that will be used later in deploying your Infrastructure as Code.

  1. Setup GitHub Repo (SNOW Automation)

  2. Populate Azure SP creds in GitHub Actions secrets store (SNOW Automation)

  3. Define Terraform backend.tf (SNOW Automation) a. Terraform version b. Terraform Azure provider version c. State file location

  4. Define variables

  5. Define GitHub Actions workflows a. Decide which event(s) trigger workflows.

    • Additional details about Event Trigger workflows, can be found here.

    • Additional details about Worflow syntax for GitHub Actions (e.g. push, pull requests, scheduling, etc.), can be found here. b. Terraform Plan c. Code Scanning d. Other workflows (secrets scanning, unit tests, etc…) e. Terraform Apply

Write Code Following these steps will remove the inefficent process of deploying resources via the Azure Portal. You can declare your infrastructure in code and will be deployed securely and reliably through a CI/CD pipeline.

  1. Develop main.tf and optionally other tf files according to the blueprints in ADO

  2. Minimally develop GitHub Actions workflows a. terraform-plan.yml b. terraform-apply.yml

  3. Use linter to check and format code

Version Control Utilizing Version Control in your infrastructure has many advantages like having an audit trail of every single change that goes into your environment, building automated testing into your pipeline with GitHub Actions, and finally easily promoting changes from dev to staging to production.

  1. Create a branch

    1. When you’re working on a project, you’re going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow.

    2. When you create a branch in your project, you’re creating an environment where you can try out new ideas. Changes you make on a branch don’t affect the main branch, so you’re free to experiment and commit changes, safe in the knowledge that your branch won’t be merged until it’s ready to be reviewed by someone you’re collaborating with.

    3. Branching is a core concept in Git, and the entire GitHub flow is based upon it. There’s only one rule: anything in the main branch is always deployable.

    4. Because of this, it’s extremely important that your new branch is created off of main when working on a feature or a fix. Your branch name should be descriptive (e.g., refactor-authentication, user-content-cache-key, make-retina-avatars), so that others can see what is being worked on.

  2. Add Commits

    1. Once your branch has been created, it’s time to start making changes. Whenever you add, edit, or delete a file, you’re making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch.

    2. Commits also create a transparent history of your work that others can follow to understand what you’ve done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction.

    3. Commit messages are important, especially since Git tracks your changes and then displays them as commits once they’re pushed to the server. By writing clear commit messages, you can make it easier for other people to follow along and provide feedback.

  3. Open a Pull Request

    1. Pull Requests initiate discussion about your commits. Because they’re tightly integrated with the underlying Git repository, anyone can see exactly what changes would be merged if they accept your request.

    2. You can open a Pull Request at any point during the development process: when you have little or no code but want to share some screenshots or general ideas, when you’re stuck and need help or advice, or when you’re ready for someone to review your work. By using GitHub’s @mention system in your Pull Request message, you can ask for feedback from specific people or teams, whether they’re down the hall or ten time zones away.

  4. Discuss and review your code

    1. Once a Pull Request has been opened, the person or team reviewing your changes may have questions or comments. Perhaps the coding style doesn’t match project guidelines, the change is missing unit tests, or maybe everything looks great and props are in order. Pull Requests are designed to encourage and capture this type of conversation.

    2. You can also continue to push to your branch in light of discussion and feedback about your commits. If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change. GitHub will show your new commits and any additional feedback you may receive in the unified Pull Request view.

Show Plan This is an important step to verify that your code is going to perform the changes that you intend them to do.

  1. Utilizing GitHub Actions execute terraform plan

  2. The plan command alone will not actually carry out the proposed changes, and so you can use this command to check whether the proposed changes match what you expected before you apply the changes or share your changes with your team for broader review.

Deploy Code These are where all your hard work comes to fruition and you can actually deploy your infrastructure to Azure.

  1. Utilizing GitHub Actions execute terraform apply

  2. This deploys the infrastructure to the CSP (Cloud service Provider)