Please note this is a pilot feature, to join the pilot please get in touch.
Introduction
Layered modules are designed to allow teams to update and deploy the same metadata across multiple production orgs
This allows a central team to deploy business wide updates without interrupting the development taking place in the individual orgs.
This is commonly used in cases where a business has a central team that maintains multiple region specific organisations.
Building a Pipeline with layered modules allows teams to layer their shared and org specific metadata together in an easy to understand UI.
Promoting a change
After setting up your layered module Pipeline (not done this yet? See our setup guidance here), you're ready to promote your first features.
Your layered module Pipeline should look something like this, where each module has its own corresponding set of orgs.
An update to the EU module deploys changes to the EU orgs, an update to the NA module deploys changes to the NA orgs, etc.
An update to the core module (which all orgs share) deploys changes to all orgs.
Fetching changes and creating a new feature branch
The first step is to fetch changes created in your development environment, and commit them to source control.
💡 It is important that you always create feature branches from main, to be compatible with Gearset’s branching strategy and take advantage of features like automatic merge conflict resolution.
Select the development environment where you created your changes.
Click + New Feature, and if you have a Jira or Azure DevOps board linked, select your assigned ticket.
Select a comparison filter. If you have not created a custom filter then use one of the default Gearset filters - the "on demand comparison" is a good starting point.
You'll notice that in this example core, EU have been auto selected as the modules for the comparison. This is because these are the modules linked to this sandbox.
Click Compare now, and Gearset will run a comparison between the development sandbox and your chosen modules.
Committing your changes
The comparison will run, and compare the metadata in your org with the metadata in the core and EU layer.
You can explore the comparison results to find the components you want to add to the module, and select them.
In the below example a Custom field and Custom field permissions have been selected.
After you have made your selection click Next, and you may see some Problem Analysers, before coming to the pre-deployment summary screen.
On the pre-deployment summary screen we can see our selected components, as well as a drop down menu to select a module.
We need to tell Gearset whether the new metadata should be deployed to all orgs ( core), or should be org-specific (the module, in this example EU). We’re deploying org-specific metadata, so we select EU and commit our new components.
💡 Any changed metadata will be deployed to its current module.
After the commit is complete you will be returned to the Pipeline.
Opening a pull request, and seeing your changes in the Pipeline
You can commit more changes to your feature branch, or create a pull request to the next environment in the Pipeline.
You will see your pull request waiting against the first environments in your Pipeline. We open these pull requests against all the environments because we want to make sure that any changes to core are compatible with all of our orgs.
Because this is a change to the EU module specifically, the field and permissions are only validated against EU UAT.
When you are ready for your changes to be deployed to the org (in this example EU UAT) you can promote your changes.
You will be able to use all of the Pipeline features like automatic validation, and custom testing levels . The key difference with a layered module Pipeline is that the the modules ensure that org-specific changes are deployed to only those orgs, while core changes are deployed to all.
Check out this short demo of a Pipeline in action, and please reach out to the in-app chat with any follow up questions.