Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

IMPORTANT:
Github Actions and workflow processes should be assigned to your development team who will review and fixes the notifications visible on the deployment logs. Once all log items are reviewed and fixed by your development team, the StagingPro code deployments will be successful.

...

  • StagingPro repository on your Git Organisation

  • Webhook configured environments Production, Staging, UAT

  • Storefront channels per environment

  • GitHub users developer and designer.

  • GitHub user branches

...

Anchor
isMissingRequiredParameterstrue
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

...

Q1. After giving Admin access to StagingPro Git repository, I see some autogenerated code branches e.g. Productione347c1, so should I keep the names as it is?
A1. Yes, that is correct. These environment branch names are autogenerated and required for code commit tracking. Please do not delete or rename these branches as it will affect the GitHub integration.

The branches are created i) per environment ii) per channel and iii) per team member

Q2. What is the purpose of developer branches?
A2. As best practice, developers are given their own branches so they can commit their codes to their own branch at the first instance, or for more frequent code commits at the developers convenience without affecting the environment branch.

Q3. Are there any benefits to using a developer branch over a more typical git feature branch (e.g. feature/TICKET-description-of-the-change)?
A3. Yes indeed! The developer can commit to their branch first. Once the task is complete, they can merge the code from their branch to the environment branch. If many developers are working on a common task, they can commit codes to each of their individual branches without affecting the other developer branches. And can merge their code easily.

Q4. What purpose does the Main/Master branch serve in a typical setup?
A4. Master branch is generally used as a buffer branch and is the default branch while creating a repo in GitHub. This master ‘buffer’ branch can be left as it is. Instead use the autogenerated active branches that is automatically (with a name such as Productione347c1) created during your GitHub integration and linking process.

...

Q6. When I commit changes in Github, will those changes will appear as rollback options in StagingPro?
A6. Correct. After the GitHub integration is set, commit changes are tracked and rollback options are visible on the deployments grid.

Q7. Can you explain how version control works for StagingPro with multiple development teams as part of existing CI/CD pipelines?
A7. When you successfully configure the GitHub integration on your StagingPro tenant, your GIT commits will be visible on the ‘Code Deployment’ tab which displays incremental version numbers. The code branches are created i) per environment ii) per channel and iii) per repo team member. Refer the ‘StagingPro Git Branch workflow’ section of this document. Under Settings > Status Notifications you can enable the Deployment Notifications checkbox for team notifications through i) Email ii) Teams and iii) Slack for shared visibility and effective collaboration.