Managing code across development, QA, and production environments requires a disciplined code configuration strategy to ensure stability, traceability, and controlled delivery. This post outlines a practical branching and release packaging model using three active branches: N (Prod), N+1 (QA), and N+2 (Dev). A clear and structured code configuration approach is essential for any organization following Agile or CI/CD practices.

Why Code Configuration Matters

Code configuration refers to the organized process of maintaining and controlling code versions, access, and changes across different environments. In large-scale or distributed teams, having a robust code configuration strategy avoids overlaps, missing changes, and release chaos. It ensures that every fix or feature is tracked and delivered to the right environment at the right time, with full visibility into its lifecycle.

Without proper code configuration, teams often suffer from duplicated bugs, missed hotfixes, or unstable releases. A structured model simplifies release coordination, automates consistency, and reduces technical debt.

Code Configuration Through Branching Strategy

Maintain three active branches to represent the current stages of your release lifecycle part of your code configuration framework:

• Branch N – Represents the Production version

• Branch N+1 – Represents the QA version

• Branch N+2 – Represents the Development version

Proper code configuration involves assigning branch access based on team roles. A Configuration Manager can oversee access controls and track change management across these branches.

Access & Workflow Scenarios

✅ Scenario 1: Production Issue (Hotfix)

When an issue is identified in production:

• The fix is applied to Branch N (Prod).

• The change is then merged forward to Branch N+1 (QA) and Branch N+2 (Dev) to maintain consistent code configuration across environments.

• The developer must have access to all three branches.

• Two release packages are prepared:

  • One for Production

  • One for QA (to validate the fix in lower environments)

✅ Scenario 2: QA Defect

When a defect is discovered during QA:

• The issue is fixed in Branch N+1 (QA).

• The fix is then merged into Branch N+2 (Dev).

• The developer needs access to Branch N+1 and N+2.

• Only one release package is created—for QA testing.

✅ Scenario 3: Ongoing Development

For feature development or enhancements:

• Code is checked in only to Branch N+2 (Dev).

• The developer requires access only to N+2.

• No separate release package is prepared immediately. A collective package is built when a new release is planned, encompassing all completed enhancements.

This structured code configuration approach ensures that production remains stable while development continues in parallel.

Managing the Release Cycle with Code Configuration Discipline

At the end of a release cycle:

• Branch N (older Prod version) becomes obsolete and can be archived or removed.

• Branch N+1 is promoted to become the new Production branch (N).

• Branch N+2 becomes the new QA branch (N+1).

• A new Branch N+3 is created for ongoing development.

This rolling model ensures that:

• No changes are lost

• Fixes are not accidentally overwritten

• Releases are consistent and well-audited

Version Control Tools

To implement this effectively, use reliable Source Code Management (SCM) tools that support branching, merging, and tagging, such as:

• SVN (Apache Subversion)

• VSS (Visual SourceSafe) (legacy)

• Modern alternatives: Git, Bitbucket, GitLab, or GitHub

These tools enhance code configuration by enabling:

• Change history tracking

• Branch management

• Tagging for releases

• Merge conflict resolution

• Audit logs and traceability

Integrating them with CI/CD pipelines makes deployments faster and safer.

This branching model strikes a balance between control and flexibility, supporting rapid development without compromising production stability.