3.1.2: Branching and Merging for Adobe Commerce Cloud Certification (AD0-E716, AD0-E717)

Now…If you’re looking for the 3.1.2: Branching and Merging for Adobe Commerce Cloud Certification (AD0-E716, AD0-E717) video, you’ve found it. In this step by step video, you’ll learn exclusive tips from the smartest engineers…

3.1.2: Branching and Merging for Adobe Commerce Cloud Certification (AD0-E716, AD0-E717)

See more: https://swiftotter.com/certifications
—-
The Cloud series of videos is first coming to YouTube. We will move this content into it’s own course soon. We are doing this because of the sudden change to drop the non-Cloud certifications. Enjoy watching!
—
3.1.2: Branching and Merging
Cloud environments have hierarchical relationships, starting with the Master environment (equivalent to Production on Starter). Pro projects are provisioned with Production, Staging and Integration environments in a direct hierarchy; the recommended workflow for Starter is also to create a Staging environment from Master and an Integration environment from Staging.

The intent of this environment hierarchy is to facilitate good testing and deployment practices. New code changes should be pushed into the Integration environment for initial testing and, once determined stable, merged back into Staging for final testing and then to Production for deployment to the live site. (In Pro, any changes merged into Production are also expected to be immediately merged into Master.) This is a familiar version control workflow; in Cloud, the environment hierarchy applies not only to the flow of Git operations, but also to environment variable inheritance and data syncing.

🔵 Reminder: For both Starter and Pro, one other active environment beyond “Production ▶️ Staging ▶️ Integration” structure is allowed. This environment can be used for whatever feature testing/prototyping needs you have.

A couple of key notes about creating new environments:
▪️On Pro, environments cannot be branched from Staging or Production.
▪️It’s strongly recommended to branch new environments from Integration.

Let’s take a look at the methods that can be used to branch new environments and merge changes back up the hierarchy.

Using Git
Since your Cloud project repository is a typical Git repo, you can perform any and all typical Git operations, including manually creating a branch from another. (Users must have the appropriate permissions to push such new branches to the remote repository.) If using this method for branching, there are a couple of caveats to keep in mind:

▪️This will not automatically provision an active environment; it will initially result only in a Git branch (i.e., an “inactive” environment). You can, however, manually “activate” such an environment, provided you have the remaining available slots.
▪️Regardless of where you create your branch in the Git tree, and where other branch pointers are, pushing a manually created branch will not record hierarchy in the Cloud environment; the new branch will be considered a child of Master for the purposes of data syncing, variable inheritance, and merging with the Cloud tools. For this reason, it’s best to use one of the other methods for initial branching.

Merging can be done in typical Git fashion (even if the initial creation of a branch/environment was done with the Cloud tools). If a code update is merged into a branch matching an active environment and pushed, a redeployment will update the state of that environment.

Using the Project Web Interface
When accessing an environment via the Project Web Interface, a new environment can be branched from it (provided there are enough remaining slots). This is done using the appropriate task widget as shown and providing a name for the new environment.

Creating an environment in this way will maintain its hierarchical relationship with the environment it is branched from, will result in a new Git branch in the remote repository, and will automatically kick off the provisioning of a new active environment based on the parent’s files and data

The merging process works much the same way. A merge widget is available that will kick off the merging of an environment’s code state into its parent and the immediate re-deployment of that parent

Using the Cloud CLI Tool
A set of commands in the Cloud CLI Tool support branch management

🔵 Reminder: Remember that the Cloud CLI commands will infer the project and environment context from the local code state. If you run these commands outside a local project context, however, or wish to execute a command for a different environment, you can use the –project/-p and –environment/-e options

Further Reading
Clone & Branch Management: https://experienceleague.adobe.com/docs/commerce-cloud-service/user-guide/develop/cli-branches.html
—
Connect with Chris
Twitter: https://twitter.com/ChrisNanninga
LinkedIn: https://www.linkedin.com/in/chris-nanninga-0b90a416

Connect with Joseph:
LinkedIn: https://www.linkedin.com/in/maxwelljoseph/
Twitter: https://twitter.com/swiftotter_joe

https://swiftotter.com
Tweets by Swift_Otter
https://www.facebook.com/SwiftOtterInc

Have you joined the free SwiftOtter Slack community? It’s exploding and we don’t want you to miss out. Go to https://swiftotter.com/slack to join for free and get plugged into what might be the best group of collaborating developers around

Related reading: