Example of a Release and Git strategy

Release Strategy

The release scheme is designed taking into account the specifics of the project and the amount of development.

Main features:

-          source of truth git;

-          Interaction with other vendors via git;

-          maximum transparency of changes;

-          minimum labor costs for deployment;

-          deep automation is possible;

-          ability to return to the previous state of the system (git) at any time;

-          transparent system for estimating labor costs for any deployment. 

Where:

Git Branch:

Salesforce Org (prod/sandbox/scratch) - environment: 

Environments:

Dev1… DevN environment - development environment (dev sandbox or scratch org, updated from the Int branch as needed);

Int environment - integration environment (updated from the Int branch every time deploy from dev environments, merge with changes from another vendor or changes from the HotFix branch), it is recommended to run unit tests on this environment. (Unit tests)

QA environment - deploy occurs automatically, it is recommended to deploy at least once a day. (Unit tests, System/Functional test, Smoke tests)

UAT environment - deploy occurs automatically, deployment is automatic, as needed. The customer's qa team may be present in this environment. (Unit tests, User acceptance tests)

PreProd environment - deployment to this environment occurs at the end of the release. Here is the final check of all changes to the current release. For short releases, the environment may be missing.

HotFix environment - must match the state of the prod for Troubleshooting on the prod.

Branches:

Feature branch -  it is used to transfer changes from the developer to the project repository.

Feature branches should look like: feature/<Jira Key>
for example: feature/JK-1010

Int branch - common branch for development. All developers merge his branches to this branch. Merges with other vendors also occur in this branch via a merge request

Int branch should look like: int/<name>

for example: int/ct-ABC

Release branch - in this branch there is a merger of developments prepared within the current release.

Int branch should look like: release/< release/sprint number>

for example: release/mc-r1.0-spint1

Important: the release branch changes when change the release or sprint. Initially created by cloning the int branch.

HotFix branch - a branch is created by cloning the master branch. In this branch, developers make merges only for fixing the release.

HotFix branch should look like: release/< release/sprint number>-fix

for example: release/mc-r1.0-spint1-fix

HotFix feature branch -  it is used to transfer changes from the developer to the project repository - only for fixing the release.

Feature branches should look like: feature/<Jira Key>-fix
for example: feature/ABC-1010-fix

 

The branch strategy

Where:
1 - cloning
2 - merge request
3 - git pull (this operation is necessary to resolve merge conflicts locally by the developer

Step-by-step process (developer)

1.       The developer clones the project directory from the Int/HotFix branch
2.       The developer creates a local feature branch
3.       The developer creates changes and tests them on the dev environment
4.       a commit is being created
Important! commit should look like “< Last name and First name of the developer > < Jira Key>"
5.       Makes a push of its branch to the repository
6.       Makes a pool of int branches (if there are conflicts it resolves them)
7.       Does validation on an int environment (fixes errors if necessary)
8.       Makes a push of its branch to the repository
9.       Creates a merge request and sends the lead for approval
Important! it is recommended to use “Squash commits”
10.   After the lead approves the merge, an automatic deployment to the int environment takes place

Step-by-step process (working with changes from third-party Release )

1.       The specialist clones the branch and push it to the project git repository
2.       The specialist creates a merge request
3.       A specialist clones a vendor branch to his computer
4.       Makes a pool of int branches (if there are conflicts it resolves them - if necessary, the specialist contacts the vendor or developers)
5.       Does validation on an int environment (fixes errors if necessary - if necessary, the specialist contacts the vendor or developers)
6.       Makes a push of its branch to the repository
7.   After approves the merge, an automatic deployment to the int environment takes place
 
Advantages

The implementation of the strategy opens up the possibility for deeper automation to reduce labor costs, increase speed and safety.