Important Note – Right now this approach doesn't work due to a known issue – we recommend using cherry picking approach to selectively deploy changes.
In the previous blog we covered the first steps and best practices for managing extension development leveraging branches. That is the recommended simpler approach for isolating and managing your changes using branches. Changes can be tested independently(using the share option), promoted to the main branch when ready for integrated testing, and then deployed to production. Make sure to read that blog first before reading this blog.
In this blog, we show a modified workflow for customers looking to only release some of the changes that are currently in main. The idea is that while developing extensions, the main code branch contains all the extension that are ready for testing, and is used to deploy all of them to the testing environment. For rolling to production, however, we then pick specific extensions into a release branch. That release branch will then be deployed to the production environment.
Here is a quick demo of the process we'll use, followed by a description of the steps.
Working with Branches and Merge Requests
As recommended in the previous blog, each extension should be developed in a separate branch. This lets you better control and isolate changes down the road. Once an extension is ready for the next stage, such as testing stage, we create a merge request that will merge the code into the main branch.
The main branch is the one that then gets deployed to the testing environment. Your users and quality assurance people can then test all the extensions in that environment.
Creating Release Branch
To create a release branch that only has some of the extensions we worked on, we create a new branch that has none of the extensions and then pick only the ones we want.
To create this branch, look at the log tab for the main branch and locate the version we want to start from. You'll see the commit version number which you can click to see further info about this revision.
The revision has an id that you can copy using the button next to that id.
Now go to the Ref tab of the git view and click to create a new branch providing the id from the previous step – give a meaningful name to this new branch.
We are now ready to pick the specific extensions we'll add on top of this version.
Important note, you might want to set the protection and approval properties for this release branch to only allow specific people to act on this release branch.
Re-Applying Merge Requests
Switch over to the merge requests page in Visual Builder Studio and into the merged tab. Here you can locate the merge requests (MR) that relate to the extensions that you want to pick for release. Those have already been merged into the main branch, now we want to merge them into the release branch. Go into the specific MR and click the re-apply button and target the MR to the release branch. This will create a new merge request for the specific changes to go into the release branch.
Go through the merge process, obtaining approvals as needed, and then execute the merge. We recommend that you'll use the Squash and Merge commit option – to simplify the display of commit information in the log tab for this branch.
Repeat this step for every extension you want to deploy in this release.
Deploy the Release
Our git branch now has the specific changes we want to deploy, to deploy we'll create a package and deploy pipeline in the Builds area. If you are not familiar with the package and deploy pipeline and jobs – have a read through this blog that explains the pipeline.
Create two new build jobs to package and deploy the release version. To simplify the process, choose the option to copy the existing package and deploy job when creating the new jobs. Then go into the configuration of the new jobs you created and update as needed. Specifically, for the package job, switch it to use to the release branch rather than the main branch. For the deploy job, make sure it copies the artifact from the new release-package job rather than the default one. Also switch the deployment step to point to the Fusion instance where you want the release to be deployed.