Why We Needed Squad Environments for SFCC

In a shared SFCC development model, multiple teams often work on different features at the same time. Without isolated environments, every feature competes for the same Dev environment, the same deployment path, and the same validation window.

That creates several practical problems:

• One team can break Dev while another team is trying to validate unrelated work.
• Feature testing becomes dependent on the readiness of other teams.
• Dev deployments become too risky because every merge affects everyone.
• Rollback and troubleshooting become harder because many changes arrive together.
• Manual coordination takes too much time.
• Teams cannot easily test long-running feature branches before promoting to Dev.

For CSC, we needed a cleaner flow for SFCC development across multiple squads. The goal was not only to deploy code, but to give each squad a predictable way to test, validate, and promote changes without blocking other squads.

The solution was to introduce squad-based environments, using SFCC sandboxes / MRT targets, and manage the flow through GitHub Actions.

What the Pipeline Was Designed to Solve

The pipeline was created to solve a real coordination problem.

Before this flow, the development process had too many dependencies between teams. A regular feature branch could be merged too early, deployed too broadly, or tested in an environment already affected by another squad’s changes.

The updated pipeline introduced several important controls.

Squad Isolation

Each squad gets its own deployment path. A squad can test its changes in its own SFCC sandbox or MRT environment before anything is promoted to the shared Dev environment.

This makes testing safer and more predictable.

Controlled Promotion

Promotion to Dev or Staging is not automatic after every branch update. The pipeline uses approval gates so that a validated squad build can be promoted only when the team is ready.

This reduces accidental deployments and gives stakeholders a clear checkpoint before shared environments are updated.

LRFB Support

Some work requires a long-running feature branch. The pipeline supports this through LRFB branches, such as:

feature/<squad>-lrfb-*

This allows a squad to work on a larger feature without constantly merging unfinished work into the regular squad branch.

Reduced Cross-Team Conflict

By separating squad validation from Dev promotion, the process reduces the chance that unfinished or unstable code affects other squads.

A squad can continue testing independently while another squad promotes its own validated work.

Better Visibility

The pipeline provides clearer status around what is being deployed, where it is going, and which approval step is required next.

This is important for technical teams, QA, release managers, and stakeholders who need to understand the current state without reading every GitHub Actions log.

Updated Flow

The updated flow is based on a simple idea:

Test early in squad environments, promote only after validation.

The flow starts when a developer opens or updates a pull request. The pipeline detects the branch type, squad, target environment, and whether the branch is a regular squad branch or an LRFB branch.

After that, the pipeline decides what should happen next.

Flow Diagram

The updated flow separates squad validation from shared environment promotion.

How the Pipeline Works

The pipeline has a detection stage that controls the rest of the process.

It checks:

• which branch triggered the pipeline;
• which squad owns the branch;
• whether the branch is a regular squad branch or an LRFB branch;
• whether the squad has an active reference configured;
• whether the pipeline should continue, pause, or stop;
• whether promotion to Dev or Staging is allowed.

This detection step is important because it prevents the pipeline from blindly deploying every branch.

For example, if the active reference for a squad points to an LRFB branch, regular squad branch deployment can be paused. This protects the larger feature flow from being overwritten or mixed with unrelated squad branch updates.

Example Branch Strategy

A regular squad branch can look like this:

squad/ace
squad/dpd
squad/jrny
squad/dcc
squad/am

An LRFB branch can look like this:

feature/ace-lrfb-checkout-redesign
feature/dpd-lrfb-payment-update
feature/jrny-lrfb-account-flow

The active reference controls which branch is currently allowed to deploy for that squad.

Example:

ACTIVE_REF_ACE=squad/ace

or:

ACTIVE_REF_ACE=feature/ace-lrfb-checkout-redesign

This gives the team a simple switch between normal squad work and long-running feature branch validation.

What Changed for the Teams

The biggest improvement was not just automation. The real improvement was process control.

After this pipeline, teams could:

• deploy and test independently;
• validate features before promoting to shared environments;
• reduce waiting time between squads;
• avoid unexpected changes in Dev;
• use approval gates before promotion;
• keep long-running feature work isolated;
• troubleshoot failures with better context;
• understand which branch is active for each squad.

This made the development and release flow more predictable.

Why MRT / Sandboxes Matter

For SFCC projects, environment availability is critical. If all teams depend only on one shared Dev environment, development slows down quickly.

MRT and sandbox-based deployment targets make it possible to validate squad-specific work earlier. This is especially useful when frontend changes, SFRA updates, configuration changes, and integration testing need to happen before Dev promotion.

The pipeline connects GitHub branch strategy with these environments, so deployment is not just manual environment management. It becomes part of the CI/CD process.

Practical Result

The final result was a pipeline that supports a more stable SFCC delivery model:

Feature / Squad Branch
        ↓
GitHub Actions CI
        ↓
Squad Sandbox / MRT Deployment
        ↓
Squad Validation
        ↓
Manual Approval
        ↓
Dev Promotion
        ↓
Validation
        ↓
Staging Promotion

This flow gives teams more independence while still keeping control over shared environments.

It also makes the promotion process more transparent. Instead of asking what was deployed and where, the pipeline shows the current path and status.

Lessons Learned

The main lesson is that CI/CD for enterprise SFCC projects is not only about running builds and deployments.

It also needs to support how teams actually work:

• multiple squads;
• parallel development;
• long-running feature branches;
• shared Dev and Staging environments;
• approval requirements;
• release coordination;
• rollback and troubleshooting.

A simple pipeline is not enough when several teams are working on the same platform. The pipeline needs to understand the branch model, the squad model, and the environment model.

That was the reason for introducing this GitHub Actions flow.

Conclusion

The GitHub pipeline for CSC SFCC squad environments was created to make development safer, more controlled, and less dependent on one shared Dev environment.

By introducing squad-based sandboxes and MRT deployments, each team gained a better place to validate work before promotion. Approval gates added control. LRFB support made larger feature work possible without disturbing the regular squad flow.

The result is a practical CI/CD model for SFCC projects where teams can move faster without losing control over shared environments.