Release management strategies

Learn about the principles that inform SRE.ai's Pipelines feature.

Overview

An effective release management process requires a stable, practical 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 outlines the efficient, reliable, and sustainable management and deployment of software across various environments (e.g., development, testing, staging) used in the software development process.

An environment strategy may include automation techniques and measures to ensure proper configuration and maintenance of the environments.

SRE.ai provides instances that connect to Salesforce environments (Production, Sandbox, or Scratch Orgs) and abstract the underlying environment, which may change over time.

You can assign an instance to a branch that reflects the current state of the environment.

You can also connect such an instance to a parent instance representing the next environment in the release process. For example, a child instance for development can connect to a parent instance for quality assurance.

A parent instance can have multiple child instances, forming a hierarchy. The hierarchy enables features to flow forward to the parent instance through the promote process. Features can flow backward to other child instances through the back promotion process.

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.

In a Branching Strategy, developers typically create a separate branch for each new feature. By default, each separate branch originates from the repository's designated main branch. This approach ensures that the new feature builds on a stable version of the code.

A repository can have a main branch other than "main", for example, you can have a long-term project represented by a long-term repository. When you create a feature branch from an instance connected to the long-term repository, it will be based on the long-term main branch rather than "main" or "master". This eliminates the need for frequent merging, which better aligns with certain project milestones.