From a32455c8658fd64ab490d38a464cababb054de21 Mon Sep 17 00:00:00 2001 From: Laurence Barker <84768461+barkerl@users.noreply.github.com> Date: Wed, 10 Jul 2024 15:16:02 +0100 Subject: [PATCH] Update docs/rfc/rfc-007-static-nonprod-platform-environment.md Co-authored-by: JoshuaLicense --- docs/rfc/rfc-007-static-nonprod-platform-environment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rfc/rfc-007-static-nonprod-platform-environment.md b/docs/rfc/rfc-007-static-nonprod-platform-environment.md index b54d0c3e6f..7ea4254888 100644 --- a/docs/rfc/rfc-007-static-nonprod-platform-environment.md +++ b/docs/rfc/rfc-007-static-nonprod-platform-environment.md @@ -8,7 +8,7 @@ This RFC proposes having a static platform environment (possibly QA) to be used ### Application container release pipeline -As per [rfc-005](https://github.com/dvsa/vol-app/blob/main/docs/rfc/rfc-005-add-terraform-to-mono-repository.md) the scope of terraform code deployed to the application repo was limited to prevent further Terraform dependency complexity. As the time of writing this has not been superseded by any future request for comment that amends this stance. +As per [rfc-005](./rfc-005-add-terraform-to-mono-repository.md) the scope of terraform code deployed to the application repo was limited to prevent further Terraform dependency complexity. As the time of writing this has not been superseded by any future request for comment that amends this stance. The existing pipeline fundamentally guides the deployment of containers to ECS clusters that sit upon the entirety of the VOL cloud infrastructure. Any change to just the container image (which as per current understanding will be a significant amount of the change requests going forward) will be efficient as per design. This means that container change will be ready for rapid promotion through the remaining three environment leading to decrease in release cadence.