> ## Documentation Index
> Fetch the complete documentation index at: https://engineering.unkey.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Pulumi Workflow

> Day-to-day Pulumi deployment workflow.

## Table of contents

* [Pulumi Workflow](#pulumi-workflow)
  * [Overview](#overview)
    * [Prerequisites](#prerequisites)
  * [Steps](#steps)
    * [1. Create a Feature Branch](#1-create-a-feature-branch)
    * [2. Make Your Changes](#2-make-your-changes)
    * [3. Test Locally (if possible)](#3-test-locally-if-possible)
    * [4. Commit and Push Changes](#4-commit-and-push-changes)
    * [5. Create Pull Request](#5-create-pull-request)
    * [6. CI/CD Pipeline Execution](#6-cicd-pipeline-execution)
    * [7. Deployment Order](#7-deployment-order)
    * [8. Monitor Deployments](#8-monitor-deployments)

## 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

```bash theme={"theme":"kanagawa-wave"}
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...

```yaml theme={"theme":"kanagawa-wave"}
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)

```bash theme={"theme":"kanagawa-wave"}
# 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!

```bash theme={"theme":"kanagawa-wave"}
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