Skip to main content
All CollectionsAutomationPipelinesLayered Module Pipelines
Modularizing a repository using the setup wizard for layered modules
Modularizing a repository using the setup wizard for layered modules

This article describes the process of using the setup wizard for Layered Modules to convert the structure of an empty repository.

Sravani Bhattiprolu avatar
Written by Sravani Bhattiprolu
Updated this week

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.

Modularizing a repository

In order to support the creation of new modules in your repository, you must convert the structure of your repository. You can do this through Gearset's automated modular repository setup.

  • First step is to create an empty repository in your chosen source control provider. Make sure to initialise it with a Read Me file as shown below. I am using GitHub in this example.

  • Connect your source control to Gearset by navigating to My connections on the left-hand side menu and click on Source control and services. More detailed steps provided here.

  • Navigate to the compare and deploy page and select the main branch of your newly created repo as the target. You will see an option to Set up repository as shown below.

  • Once you click Set up repository, it will take you through the setup wizard. After reading each step, click Next.

Step 1 - What does it mean to modularize a repository?

This process will allow you to create modules within a single repository. You will be able to define sets of metadata as core (shared between your orgs) or layered (belonging to specific orgs).

Step 2 - What do you mean by create a module?

A Gearset module is a folder in your repository that contains your org's metadata. After creating the folder for the core module, any subsequent org-specific layered modules created will follow the same structure

Step 3 - How do org-specific layered modules work?

Creating an org-specific module will generate a new module, and layer it with the existing core module. When you make a deployment to that org, any org-specific metadata will be layered with the shared metadata from core.

Step 4 - Why create a layered module?

The core module allows you to deploy shared metadata to multiple orgs in one deployment without the danger of overwriting your org-specific customizations. The layered modules allow you to make deployments to specific orgs, without disrupting the shared metadata.

Step 5 - How should you segment your code into modules?

If metadata is shared between all orgs, it can be placed in the core module. Metadata specific to individual orgs should be placed in the relevant org-specific module.

Step 6 - Convert repository

At this step, you will see a warning message telling you that you are about to change your repo structure. If you wish to continue, click the checkbox for I understand that this is a permanent change and click Convert repository.

Step 7 - Commit to core

If you have a set of metadata you already know is shared between your orgs this should be committed to the "core" module.

Step 8 - Create a new module

Once you commit the metadata to the core module, it is time to create your org specific modules. You can do it by clicking on + Create new Module.

You will be presented with a new window to create a new layered module. Enter the module name and click Create.

Step 9 - Commit to new module

You will now have the option to commit to the newly created module as shown below. If there is metadata specific to only one of your orgs, that should be committed to the org specific module by selecting that module.

This doesn't have to be done all at once so take a pause and plan how you'd like to build your modules.

  • If you have a set of metadata you already know is shared between your orgs this should be committed to the "core" module.

  • If there is metadata specific to only one of your orgs, that should be committed to the org specific module.

We have a guide with more information on this process here.

Next steps

Once you have created your modules you will be able to set up a Pipeline to deploy to multiple production orgs.

Check out these articles next:

Did this answer your question?