1

We are developing modules for a web app that are released in parallel. We are trying to figure out a good branching strategy to keep an overview of the released modules. This is our current system:

  • Master: contains all released modules / code (matches production)
  • env/test: Branch that is deployed to the testing environment
  • env/acceptance: Branch that is deployed to the acceptance environment
  • env/production: Branch that is deployed to the production environment

Since modules are being developed and released in parallel one module could be started after another and be released earlier. To make this work a new module starts with a feature branch from master. This feature branch is squashed merged into env/test to create a single commit for the new module. Now the difficult part starts. To prevent merges into the env/* branches we have added a policy to force squash merges. For test this is working correctly since it is the first place a new module / feature is merged to. When we squash merge into acceptance / production and master we loose a reference between master and the env/* branches. We would like to maintain a reference so we can check how much acceptance is ahead of master (unreleased modules in acceptance stage).

We know this is not the best solution but are struggling to figure out a better strategy. The clients really want to maintain the parallel development since some modules can take months in the acceptance stage (many stakeholders ect) and some can be released in a week. Using a fixed numbered release system would delay some modules and would introduce other issues when a module is cancelled during acceptance.

Erik A
  • 31,639
  • 12
  • 42
  • 67
Herman Kruisman
  • 133
  • 1
  • 11

1 Answers1

0

Split the repository into one repository for each module (this approach is used for microservices, and generally is used on GitHub for open source modules). Then each repository can have separate branches, separate versioning scheme, etc.

Robin Green
  • 32,079
  • 16
  • 104
  • 187
  • but how do you work with module interaction? Then you have a dependency outside of you own repository. – Herman Kruisman May 07 '18 at 14:42
  • That's where the separate versioning comes in. You should use semantic versioning (semver.org) for each module and then bump the version as appropriate whenever you need to make a change in one module to depend on it in another module. – Robin Green May 07 '18 at 15:12