Skip to content

Configure infrastructure

Prepare an existing application for the new deployment pipeline by making some small infrastructure changes.

Before you begin

Step 1: Configure the cicd-common stack in dev

Add your application repository to config_override.tf. The configuration differs depending on your repository type.

  • Application repo — the repository contains code for a single application, while the associated infrastructure lives in a separate IaC repository (e.g., pirates-iac).
  • Application monorepo — the repository contains code for multiple applications, while the associated infrastructure lives in a separate IaC repository (e.g., pirates-iac).
  • Application repo w/infrastructure — the repository contains both application code and the associated infrastructure for a single application.

Select the tab that matches your repository type:

Make the following changes:

repo-iac/environments/dev/cicd-common/config_override.tf
locals {
  trusted_repositories = [
    # ...
    {
      name = "<repo-name>"
      type = "app"
    }
  ]
}

Update these values:

Field Description Example
<repo-name> The name of your application repo pirates-app-zebra

Make the following changes:

repo-iac/environments/dev/cicd-common/config_override.tf
locals {
  trusted_repositories = [
    # ...
    {
      name = "<repo-name>"
      type = "app"
      apps = [
        # Add more as needed
        "<app-name>"
      ]
    }
  ]
}

Update these values:

Field Description Example
<repo-name> The name of your application monorepo pirates-apps
<app-name> The name of your application too-tikki

Make the following changes:

repo-iac/environments/dev/cicd-common/config_override.tf
locals {
  trusted_repositories = [
    # ...
    {
      name = "<repo-name>"
      type = "hybrid"
    }
  ]
}

Update these values:

Field Description Example
<repo-name> The name of your application repo w/infrastructure pirates-app-swordsmith

Step 2: Configure the application stack

In a stack using an app or cloudfront-static-website template, enable the new deployment mechanism:

repo-iac/environments/dev/app-example/package-config.yml
DeploymentPipelineV2:
  Enable: true

Install the package:

repo-iac/environments/dev/app-example/
ok pkg install

For existing ECS container applications: Avoid downtime

DeploymentPipelineV2 sets the ECS container's image URI (local.image_uri) automatically based on an image tag that's read from SSM Parameter Store (local.artifact_tag). During initial setup, the tag will contain a placeholder value ("null") because the new CI/CD pipeline hasn't run yet.

In critical environments, add a fallback value in config_override.tf to prevent downtime that can occur from trying to deploy a non-existent image:

locals {
  image_uri = (
    local.artifact_tag != "null" ?
    "${local.account_id}.dkr.ecr.${local.region}.amazonaws.com/${local.environment}-artifact:${local.artifact_tag}" :
    "<fallback-image-uri>"
  )
}

Update these values (you can find your current image URI in the ECS console in AWS):

Field Description Example
<fallback-image-uri> The URI of an image to use on the first deploy 123456789012.dkr.ecr.eu-west-1.amazonaws.com/my-repo:my-tag

Step 3: Create a pull request

Create a pull request with your changes. GitHub Actions runs automatically and shows the planned changes in the pull request.

The plan contents depends on your set up, but based on a standard setup of a container application using Golden Path, the plan will contain:

  • A new SSM parameter for storing artifact references
  • ECS service configured to have Terraform wait for container health checks to succeed through wait_for_steady_state
  • IAM resources from the old CI/CD setup will be removed
  • IAM resources for the new CI/CD setup will be added
  • Various changes in environment variables, Terraform outputs, variables

Be sure to check that the image_uri in the task definition is either the image you provided in the workaround (see warning above), or otherwise an expected image (not an image tagged with "null").

If you are unsure whether changes are safe to apply, don't hesitate to contact Utviklerflyt.

Step 4: Merge the pull request

Merge the pull request and let the Terraform apply workflow in GitHub Actions apply the changes.

Step 5: Repeat for production

Repeat steps above for your production environment.

Next steps