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.
Cherry Picking Branch
After you've done the various changes and published them into main, you might decide that for the release you only want specific changes to be applied. To get only these changes, we'll create a new branch, and we'll use the cherry pick git option to pick the specific commits that will go into this branch.
You can get information about the commits looking at the git logs tab (potentially using the diagram view).
Clicking on a commit will let you copy the id to be used in cherry picking.
I'm using a separate workspace to work on the cherry pick branch, and then using the git->cherry pick option in the workspace to apply specific changes to this branch.
Merging into the Release Branch
Once you completed picking specific changes into the cherry pick branch, you are ready to merge these into the release branch. Switch over to the merge requests page in Visual Builder Studio and create a new merge request from the cherry pick branch into the release branch. This MR will only include the files that were involved in the cherry picked transactions. Once the merge request is approved, these changes will be in the release branch ready to be deployed.
Deploy the Release
Our git release 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.