Naming Snapshots in IBM BPM
I have recently enjoyed the “put your money where your mouth is" experience of leading some greenfield process improvement work and it’s my newly held view that best practices work best when they're baked into the way that everyone on the team thinks (otherwise it’s too hard to remember everything).
I want to make some suggestions around version (snapshot) labelling in IBM BPM based on my own experience:
Use a three numbered approach e.g. x.y.z (majorVersion.minorVersion.snapshotCounter).
Try and define versions from a business perspective (e.g. create a new major/minor version for a set of features).
*Always* stick to the convention. For every single snapshot.
Treat the description as you would a commit message (http://chris.beams.io/posts/git-commit/).
Put some explicit logging into your deployment services so that you can keep track of deployment dates and times across environments (you are using something like Splunk aren't you?).
Some branching-based scenarios:
Scenario 1
Imagine that you release 1.1.59 into Production.
You then start working on 1.2.1 for your next release.
A defect is discovered that needs to be addressed immediately so you create a hotfix ("1.1") branch from 1.1.59 and call the next snapshot 1.1.60 (making sure that you implement any fixes in the main branch as well).
Scenario 2
You have finished development on 1.2.19.
The next version has some big changes in so you create a "1.2" branch to support testing etc. while the new work (on 2.0.1) continues in the main branch.
Fixes in the "1.2" branch must also be made in the main branch.
When "1.2" (let's say it's 1.2.24) goes into production you should archive any old branches (e.g. "1.1").
There's a bunch of stuff on the Internet (e.g. http://semver.org/) about all of this.
I want to make some suggestions around version (snapshot) labelling in IBM BPM based on my own experience:
Use a three numbered approach e.g. x.y.z (majorVersion.minorVersion.snapshotCounter).
Try and define versions from a business perspective (e.g. create a new major/minor version for a set of features).
*Always* stick to the convention. For every single snapshot.
Treat the description as you would a commit message (http://chris.beams.io/posts/git-commit/).
Put some explicit logging into your deployment services so that you can keep track of deployment dates and times across environments (you are using something like Splunk aren't you?).
Some branching-based scenarios:
Scenario 1
Imagine that you release 1.1.59 into Production.
You then start working on 1.2.1 for your next release.
A defect is discovered that needs to be addressed immediately so you create a hotfix ("1.1") branch from 1.1.59 and call the next snapshot 1.1.60 (making sure that you implement any fixes in the main branch as well).
Scenario 2
You have finished development on 1.2.19.
The next version has some big changes in so you create a "1.2" branch to support testing etc. while the new work (on 2.0.1) continues in the main branch.
Fixes in the "1.2" branch must also be made in the main branch.
When "1.2" (let's say it's 1.2.24) goes into production you should archive any old branches (e.g. "1.1").
There's a bunch of stuff on the Internet (e.g. http://semver.org/) about all of this.