# 006 - Pipeline Changes

Last Modified: July 7th, 2025

Title: Standardization and Modularization of CI/CD Pipelines

Status: Implemented

---

# Context

# What is the background to this decision?

Our CI/CD pipelines had grown inconsistent and difficult to manage across projects. Logic was duplicated, outdated YAML and Jenkins files were still present, and deployment steps were not clearly separated from validation steps. This led to confusion, increased maintenance overhead, and security concerns due to unmanaged variables and inconsistent environments.

To address these issues, we needed to:

• Modularize and centralize pipeline logic.
• Improve clarity and maintainability.
• Align with best practices for secure and scalable CI/CD.

---

# Decision

# What decision have you made?

We have restructured our CI/CD pipelines by:

• Removing legacy and modularized logic.
• Relocating all CI/CD-related files into a top-level infra/ folder.
• Creating two standardized pipelines per project:
  1. PR Pipeline: Runs on pull requests and includes linting, static type checks, security checks, and unit tests.
  2. CICD Pipeline: Runs on pushes to main branches (dev, qa, pent, preprod1, prod1, ) and handles deployment to AWS (BE) or Cloudflare(FE).

---

# Rationale

# Why did you choose this decision?

1. Clarity and Maintainability: Separating validation and deployment pipelines improves readability and reduces cognitive load.
2. Security: Using variable groups and avoiding inline secrets enhances security.
3. Scalability: Modular design allows reuse across multiple projects.
4. Consistency: Python-like naming conventions and centralized environment definitions ensure uniformity.
5. Performance: Custom build agent pools optimize execution time.

---

# Implications

# What are the implications of this decision?

1. People/Training:

   • Minimal training needed due to Python-like naming and simplified structure.
   • Developers need to understand the new folder structure and pipeline triggers.

2. Process Adjustments:

   • Teams must follow the new two-pipeline model.
   • PRs must include updates to the infra/ folder when needed.

3. Tooling:

   • Adoption of variable groups and custom agent pools.
   • Removal of Jenkins and legacy YAML files.

4. Risks:

   • Initial migration effort for existing projects.
   • Potential misconfigurations during early adoption.

---

# Trade-Offs

# What are the pros and cons of this decision?

• Benefits:

  • Improved pipeline clarity and modularity.
  • Enhanced security and environment management.
  • Easier onboarding and debugging.

• Drawbacks:

  • Initial setup and migration effort.
  • Slight learning curve for teams unfamiliar with the new structure.

---

# Key Evaluation Metrics

# How will success be measured?

• Reduction in pipeline-related incidents or failures.
• Decrease in average pipeline execution time.
• Fewer duplicated pipeline definitions across repositories.
• Increased adoption of standardized pipeline templates.

---

# Conclusion

# What is the final recommendation?

We recommend adopting the new CI/CD pipeline structure across all projects. The benefits of clarity, security, and maintainability outweigh the initial migration effort. This decision sets a strong foundation for scalable and secure DevOps practices moving forward.