Release management strategies
Learn about the principles that inform SRE.ai's Pipelines feature.
Overview
An effective release management process requires a stable environment strategy and a clear branching strategy.
Read below to learn about the optimal environment and branching strategies that inform SRE.ai's Pipelines feature.
Read SRE.ai's Pipelines documentation for more information.
Environment strategy
An environment strategy defines how software is managed and deployed across environments such as development, testing, and staging. It typically includes automation and configuration controls to keep environments consistent.
In SRE.ai, instances connect to Salesforce environments (Production, Sandbox, or Scratch Orgs) and abstract the underlying environment, which may change over time.
Each instance is assigned to a branch that reflects the current state of that environment. You can also connect an instance to a parent instance representing the next environment in the release process. For example, a development instance connected to a quality assurance instance.
A parent instance can have multiple child instances, forming a hierarchy. Features flow forward to the parent through the promote process and backward to child instances through back promotion.
A typical Environment Strategy may look like this:

Branching strategy
A Branching Strategy organizes and stores different versions of code in a source control repository.
A branch represents a separate line of development. Branches enable multiple developers to work on the same codebase simultaneously without affecting each other's work.
SRE.ai uses a hybrid git branching strategy that combines the best of Feature Branching and GitFlow.
Developers typically create a separate branch for each new feature. By default, each branch originates from the repository's designated main branch, ensuring the feature builds on stable code.
A repository's main branch doesn't have to be named "main." If you have a long-term project with its own repository, feature branches created from a connected instance will base off that repository's main branch instead. This avoids frequent merging and better aligns with project milestones.

Last updated

