# Pipeline Deployments Guide

This guide covers the infrastructure standards and processes for IBP pipelines and resources. It outlines how new repositories are set up, how CI/CD pipelines are structured, how Terraform is used to manage resources, and how infrastructure changes are promoted through environments.

# 1. New Pipelines & Repositories

# Requesting a New Pipeline

For any new pipeline, reach out to both the Software Architecture Team and the Infrastructure Team. They will coordinate the creation of the required repositories and pipeline configuration.

# Repository Structure

Each new pipeline will have two dedicated repositories created — one for the Backend (BE) and one for the Frontend (FE). Each repository follows the standard IBP structure, which includes an infra/ folder containing:

Pipeline definitions
Terraform configuration
Pre-commit hooks

# Pipeline Types

Two pipelines are created per repository:

Pipeline	Trigger	Purpose
`_pr`	All non-main branches	Runs code checks only. Used to validate changes before they are merged.
`_cicd`	All main branches (`dev`, `qa`, `preprod1`, `pent`, `prod1`)	Runs code checks and deploys to the corresponding environment.

# 2. Code Quality Gates

Code checks are a mandatory blocker. A branch cannot be deployed until all checks pass.

Check Type	Description	Blocker?
Linting	Code style and formatting validation	Yes
Static Type Checks	Type correctness verification	Yes
Security Checks	Vulnerability and security scanning	Yes
Unit Tests	Automated unit test suite	Yes

# Unit Test Requirements

Unit tests must be written to cover all cases of the code being developed. Coverage is expected to be comprehensive.

Note: Coordinate with the QA Team when writing unit tests to ensure coverage standards are met and test cases are aligned with acceptance criteria.

# 3. Infrastructure Resources & Terraform

# Validate Before Committing to Terraform

New infrastructure resources can be initially tested and validated in one of the following ways before being codified in Terraform:

Created manually in the AWS console to confirm the resource works as expected
Run locally using Terraform (terraform plan / terraform apply) against a dev environment

Once the resource is confirmed to be working correctly, it must be moved into the Terraform module. Any manually created resources must then be deleted.

Important: No resources should be left created manually. All infrastructure must be defined in Terraform to ensure consistency, naming standards, tagging, and control across all environments.

# Why Terraform for All Resources?

Managing all infrastructure through Terraform provides the following guarantees across every environment:

Consistency — all environments are provisioned to the same standard
Control — changes are tracked, reviewed, and version controlled
Naming conventions — resources are named according to IBP standards
Tagging compliance — resources are tagged correctly for cost allocation and auditing

# Getting Help with Terraform

If you need assistance creating or configuring resources in Terraform, reach out to the Software Architecture Team and the Infrastructure Team. They can provide guidance on module structure, naming conventions, and environment-specific configuration.

# 4. Deploying Infrastructure Changes

Infrastructure changes follow a specific promotion path that keeps them separate from regular feature code changes. This prevents infrastructure work from blocking ongoing feature releases.

# Promotion Path

Step	Action	Notes
1	Develop & validate	Create resources manually or test locally. Once confirmed working, codify in Terraform and delete manual resources.
2	Merge to `dev`	Merge your infrastructure branch directly to `dev` — not to the release branch. This avoids blocking other feature releases while you validate the infrastructure in dev.
3	Test in `dev`	Observe the deployment in the dev environment. Validate that all infrastructure resources are created correctly and behave as expected.
4	Merge to release branch	Once tested and confirmed working in dev, merge your branch into the current release branch.
5	Promote via release branch	The release branch is then used to deploy to upper environments (`qa`, `preprod1`, `pent`, `prod1`) following the standard release promotion process.

Important: Merge infrastructure branches to dev directly — not to the release branch — to avoid blocking other code changes. Only merge to the release branch once the infrastructure is validated in dev.

# 5. Referencing Infrastructure Resources

Never use hardcoded constants to reference infrastructure resources. All references must be dynamic and sourced from the appropriate mechanism based on the type of variable.

# Secrets

Secrets are created in Azure DevOps Library Variable Groups. Terraform is then used to create them in AWS Secrets Manager. Your code must reference the Secrets Manager variable — never hardcode secret values or reference them via constants.

# Environment Variables

For environment-related variables that are created by Terraform, use Lambda environment variables to reference them in your code. These are injected at runtime and keep your code decoupled from environment-specific configuration.

# Summary

Variable Type	Where It's Created	How to Reference in Code
Secrets	Azure DevOps Library Variable Groups → Secrets Manager (via Terraform)	Reference the Secrets Manager variable
Environment config	Terraform	Lambda environment variables

Important: Never use constants to reference infrastructure resources. Hardcoding resource names, ARNs, or secret values makes code environment-specific and difficult to maintain.

These standards ensure all infrastructure is consistent, auditable, and maintained to the same quality across every environment. When in doubt, reach out to the Software Architecture Team or Infrastructure Team for guidance.