Working with Modular Development and Unlocked Packages: Part 4
This is the fourth installment in a series exploring how to begin working with your apps in modular pieces, incorporating packages into your app development lifecycle, and what packaging may mean for your team’s change management and release processes. Over the course of this series, we’ll talk about:
Part 1: What even is a package, anyway? How can you start to experiment with segmenting your org? Part 2: How can you start to organize metadata from an app, let alone an entire org, into packages? How do you tackle organizing your metadata and projects in source control? Part 3: What do these changes mean for app builder workflows? What will happen if I install an unlocked package into my production org today? Part 4: How can you define a successful Git branching strategy that works best for most team sizes? How, when and where should packaging be added to your continuous deployment?
After you have untangled your application and set up your package directories and initial package version, it’s time to work on a strategy for managing your package versions and active development projects in your source control systems. Having a good and practical Git strategy will be crucial for your Continuous Integration and Continuous Deployment workflows. This blog post covers how to create such a strategy.
An intro to Git branching
Source control (and with that, Git) has been around for a long time in the Salesforce world. But for those who haven’t worked with Git and the Salesforce Platform yet, let’s look at briefly at a widely adapted Git branching strategy.
In a nutshell:
All active development work happens in the development branch. Creating new features or fixing bugs happens in dedicated feature or hotfix branches. Those branches inherit from development. After the feature/bug has been successfully tested, the code gets merged back into the development branch. Code that gets shipped into production gets merged from development into master. As versioning is important, the master branch gets tagged with a version number.
While that itself sounds simple, it can get a bit complicated, especially when you have multiple branches running at the same time (which is not uncommon in software development, especially when you work in a team).
Here’s a small real-world example from a code race that I did some years ago.
Blue is master, green is develop, the other are feature and hotfix branches.
Git branching strategy
Building upon that branching strategy and your own company’s requirements, you may have (or should) extend the model. Before you start designing your Git strategy you should have answers to the following questions:
At what stage in the process should automated tests run? When should unlocked package versions be created, tested, and cleaned up? How should promotion (aka installation) of package versions to environments like QA sandboxes or even production be executed?
You may answer some or all of those questions with “I want that on every commit.” But then you’ll experience the delay that