-
Notifications
You must be signed in to change notification settings - Fork 0
Release Management Strategies
To have an effective Release Management process, it is important to have both a stable, practical environment strategy and a clear branching strategy.
An Environment Strategy outlines the management and deployment of software to various environments (e.g. development, testing, staging, production) that are used in the software development process in a way that is efficient, reliable, and sustainable. It may include automation techniques and measures to ensure proper configuration and maintenance of the environments.
infinit offers instances that can be connected to Salesforce environments (Production, Sandbox, or Scratch Orgs), abstracting the underlying environment which may change over time. An instance can be assigned to a branch that reflects the current state of the environment and can be connected to a parent instance representing the next environment in the release process (e.g. a child instance for development could be connected to a parent instance for quality assurance).
A parent instance can have multiple child instances, forming a hierarchy, which enables features to flow forward to the parent instance via the promote process. Features can flow backward to other child instances through the back promote process.
A typical Environment Strategy may look like this:
A Branching Strategy is a way of organizing and storing different versions of code in a source control repository. A branch represents a separate line of development, and branches are used to enable multiple developers to work on the same codebase simultaneously without affecting each other's work.
infinit uses a hybrid git branching strategy that combines the best of Feature Branching and GitFlow. In this strategy, each new feature is typically developed in its own branch, which by default is created from the designated main branch for the repository. This ensures that the new feature is based on a stable version of the code.
A repository can have a main branch other than "main" or "master", 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 can be better aligned with certain project milestones.