CODEWITHSUNDEEP
gitreleaserelease-management
Jakub Marchwicki
Jakub Marchwicki

Reputation: 868

Release (version) commit in trunk based development

I've been looking into trunk based development recently (https://trunkbaseddevelopment.com) and what we do fits the approach nicely (small team, frequent releases, some direct commits or short-lived branches, etc.).

The only struggle I have is tagging the releases. We do CI but not every coming goes to production, and we want to increment (change) the version once the code is shipped to the customer's environment.

How in the trunk bases development (in an idiomatic way) should I do a release? How you feel with release commits on master? I can see two approaches (I'm using Java + Maven bit that's just tooling that should come in the way).

Approach #1

  1. //version information in trunk: 'SNAPSHOT'
  2. git checkout -b release/1.11
  3. // update version on release branch and commit
  4. // build the complete project and release
  5. git checkout master
  6. // continue with features

Approach #2

  1. // version information in trunk: '1.11-SNAPSHOT'
  2. git branch release/1.11
  3. // update version on the master branch to 1.12-SNAPSHOT'
  4. git checkout release/1.11
  5. // update version on release branch to '1.11' and commit
  6. // build the complete project and release
  7. git checkout master
  8. // continue with features

The second approach leaves a single commit in the repository's history, which I'm not sure how to feel about. The latter approach makes the code slightly more traceable and the release process a bit easier.

On a side note, I don't much care about bugfixes, etc. We do release a new version. But if a hotfix is required, we plan to cherry-pick

Upvotes: 5

Views: 4760

Answers (1)

danielorn
danielorn

Reputation: 6147

Instead of creating release branches just to update the versions, treat every commit as releasable in true CI/CD fashion.

  1. // Version information in trunk: "SNAPSHOT", never edited by the developers, it is only used when built locally
  2. On every push to the trunk your CI tool builds and runs all tests and creates a releasable package. Before doing anything the CI tool substitutes the SNAPSHOT version to some unique version number (see below). This change of version is never commited, it is just used for building. For easy traceability the CI tool can add the unique version as a git tag pointing to the commit (This is not strictly required if the unique version number an be derived from git information as described below)

This way all you commits to the trunk are potential releases and no additional process except for noting down the unique version shipped to the customer needs to be done as part of a release.

Regarding unique version numbers I usually let the CI tool subsitute the SNAPSHOT version to something like <git commit date>-<short git commit hash>, which has the benefits of

  • Being truly unique (thanks to the hash)
  • Being easily interpreted and compared by a human (thanks to the date)
  • Being reproduceable (thanks to using git information)

Upvotes: 6

Related Questions