Skip to main content

​
Table of contents

​
Overview

Audience: For day-to-day operations and development…

​
Prerequisites

  • GitHub Repository Access: Ensure you have appropriate access to the unkeyed/infra repository.
  • Pull Request Process: All changes should follow the standard PR review process.

​
Steps

​
1. Create a Feature Branch

git checkout -b feature/my-infrastructure-change

​
2. Make Your Changes

Each project’s deployment workflow file looks for file changes to itself, and changes to the project files. For example, the API workflow has the following… 
paths:
  - .github/workflows/pulumi-deploy-api-infrastructure.yaml
  - pulumi/projects/api/**
branches:
  - main
Any change to those files results in a workflow trigger, but only if it’s to the branch main.. so make egregious use of sandbox to validate your Pulumi changes.

​
3. Test Locally (if possible)

# Preview changes without applying them
pulumi preview --stack unkey/api/aws-sandbox-us-east-1

​
4. Commit and Push Changes

You should have git commit signing enabled, and use it! 
git add .
git commit -S -s -m "fix: description of infrastructure changes"
# follow conventional commits
git push origin feature/my-infrastructure-change

​
5. Create Pull Request

  • Open a PR against the main branch
  • Include a detailed description of the changes
  • Request reviews from appropriate team members

​
6. CI/CD Pipeline Execution

Coordinating changes across stacks might be something to consider! If you’re doing maintenance on a cluster, does it need to be taken out of Global Accelerator first? DNS changes made before work can be made?

​
7. Deployment Order

  • Changes should typically be deployed to sandbox first to ensure the pulumi code doesn’t break but go with your gut

​
8. Monitor Deployments

  • Check GitHub Actions logs for deployment status
  • Verify resources in AWS Console
  • Check application functionality