Staging Pro Repository and Branches
When you install StagingPro in your tenant, it creates a separate repository and separate branches; does not use your existing Git repository. When you add Git users in the ‘Connect GitHub’ tab, it gets associated with the separate repository associated with StagingPro.
Code commits to the respective StagingPro branch, will show up in the History & Rollback > Code Deployment tab
Staging Pro Deployment workflow
The following illustration shows the suggested ideal process as part of the Git development workflow with Pull request, that can be implemented as part of your StagingPro setup.
And the following illustration shows the suggested ideal process for hot fixes as part of the Git development workflow with direct commit to the Production environment.
As a general rule of thumb, developers first commit codes to their local branch, before it reviewed and approved for merge with a shared branch (e.g. Production branch)
After StagingPro is linked with your Git repository, the active branches are programmatically generated and these names cannot be changed.
StagingPro Git Branch workflow
As part of theme deployment workflow, consider the following StagingPro setup showing your mapped environments for Production, Staging and UAT.
Now consider GitHub users (developer and designer) added to StagingPro using the ‘Connect GitHub’ tab
The following ‘Git Branches’ illustration, highlights the flow that brings the following components together:
StagingPro repository on your Git Organisation
Webhook configured environments Production, Staging, UAT
GitHub users developer and designer.
GitHub user branches
StagingPro Git Branch Code Deployment
This is accessible under the ‘History & Rollback’ tab and click on ‘Code Deployment’ sub-tab. This shows the list of git commits of your connected GitHub repository that is visible within your StagingPro environment
Status case: Awaiting Approval
A Git commit is visible on the grid, but requires your approval before the code is merged to the respective environment.
You get two options:
Approve and Deploy - where you can deploy the code straightaway
Generate Preview and Approve Later - where you can preview the codes on a generated preview site for visual reference
Status case: If you approve the code
The code will be committed to the respective branch and you will see the status of ‘Merge Successful | Theme deployed’
You will also see a ‘Rollback’ option to rollback to a previous version if required.
Status case: If there are errors/conflicts
If a conflict is detected in config.json, click to view and resolve any errors/conflicts
Status case: If you reject the code
The status will show as ‘Rejected|Code Not approved’
