# Legacy Deployment Pipeline

This page explains how we moved from a sequential, environment‑by‑environment pipeline to a release‑based model, why we changed, and what benefits and practices define the current approach.

Our previous workflow followed a strictly sequential deployment path where code must progress through each environment in order:

---
title: Sequential Deployment (Legacy)
---
flowchart LR
  dev ==> qa
  qa ==> pent
  pent ==> preprod1
  preprod1 ==> prod1

1. Developers created feature branches off dev
2. Feature branches were merged into dev
3. Code was then promoted through each environment sequentially: dev → qa → preprod1 → pen-t → prod1

While this approach provided a structured promotion path, it presented several challenges that led us to evolve our strategy.

• Fixed Release Cadence: All feature deployments must follow the same full path, even for small changes
• Dependency Chains: Features ready for production must wait for all features ahead of them in the pipeline
• Slow Feedback Cycles: Developers receive production feedback only after full cycle completion
• Environment Congestion: Multiple features must share testing environments simultaneously

• All-or-Nothing Deployments: Features in a sprint branch must move together, complicating targeted rollouts
• Complex Hotfixes: Emergency fixes require special branching patterns that bypass normal workflow
• Difficulty Rolling Back: Reverting specific features is challenging when they're bundled with other changes
• Environment Drift: Long promotion cycles can lead to significant differences between environments

To address the limitations of our sequential approach, we transitioned to a more flexible release-based deployment model. This evolution enables faster delivery without sacrificing quality or stability.

---
title: Release-Based Deployment (Current)
---
flowchart LR
   prod1 <-.-> feat/shiny-new-feature
   feat/shiny-new-feature -.-> dev
   feat/shiny-new-feature -.-> qa
   feat/shiny-new-feature ==> release/2504
   release/2504 ==> pent
   release/2504 ==> preprod1
   release/2504 ==> prod1

Our new strategy introduces a more direct path from feature/release branches to environment branches, offering several key advantages:

• Feature-Based Deployments: Individual features can be deployed independently, allowing for targeted releases
• Parallel Promotion Paths: Critical features can follow accelerated paths while routine changes follow standard promotion
• Granular Control: Each feature can be evaluated and promoted on its own merits and timeline
• Simplified Feature Flagging: Direct deployment facilitates feature flag implementation for controlled rollouts

• Faster Feedback Cycles: Developers receive production feedback more quickly with shorter promotion paths
• Reduced Merge Conflicts: Eliminating sprint branches reduces integration complexity
• Clearer Ownership: Direct release-to-environment flow maintains clear accountability throughout the lifecycle
• Simplified Rollbacks: Individual feature deployments can be reverted without affecting other work
• Independent Testing: Features can be tested individually in higher environments without waiting for full sprint completion

• Branch Strategy: Moved from sequential environment promotion to release-based branching
• Deployment Triggers: Changed from environment branch commits to release branch deployments
• Feature Integration: Features now integrate through release branches rather than sequential environment promotion
• Hotfix Process: Simplified hotfix process with direct release branch targeting

• Environment Structure: All environments (dev, qa, pent, preprod1, prod1) remain the same
• AWS Infrastructure: No changes to underlying AWS environment setup
• Quality Gates: Same testing and approval requirements
• Security Policies: All security and compliance requirements maintained

• Clear promotion path was easy to understand
• Environment isolation was well maintained
• Quality gates were consistently applied

• Reduced deployment bottlenecks
• Increased deployment flexibility
• Simplified hotfix processes
• Better feature isolation
• Faster feedback cycles

As we continue to evolve our deployment strategy, we're considering:

• Tag-Based Deployments: Moving towards using tags with versions to deploy instead of blocking and unblocking branches
• Feature Flags: Enhanced feature flagging for more granular control
• Automated Testing: Increased automation in the deployment pipeline
• Environment Parity: Better alignment between environments

This evolution represents our commitment to continuous improvement in our development and deployment processes while maintaining the quality and reliability our customers expect.