> For the complete documentation index, see [llms.txt](https://docs.sre.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sre.ai/best-practices/release-management-strategies.md).
# 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](broken://pages/skx8XvXxnLwlmMVGvdjg) 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](https://www.gitkraken.com/learn/git/git-flow).
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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.sre.ai/best-practices/release-management-strategies.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
