Thank you Myrle for clarifying. With the constraints mentioned, I believe it is good to go with option 2.
Regards, Nazeer On Tue, Dec 12, 2017 at 3:09 PM, Myrle Krantz <[email protected]> wrote: > > With option 2) how are we going to prepare a release for 1 or 2 micro > > services? > > Very good question Nazeer, > > These are my thoughts: > > We need to decide how to version our source release, our binary > releases, and we need to decide how to enter that versioning into Jira > for the "fixed version(s)". > > Our approach will have to work within the following constraints: > * We still want to do heartbeat releases. > * We're using semantic versioning (1) for our build artifacts. In > order to get continuous integration to work, we'll need to place > versioned build-snapshots in an artifactory such as maven. > * We have multiple build artifacts, and their versioning will not be > synchronized. > * But we'd like to have one Jira project for all 33 build artifacts. > In Jira, releases belong to a project and not to a component. > * We also don't want to release each build artifact individually; we > want to create a complete release so that our users don't have to > figure out which versions work together. > * Releases are source code, but a binary artifact release in maven > would make it easiest to use our stuff. These would have to use the > semantic versioning of our build artifacts. > * Jira only has one workflow per ticket. Not one workflow per release > per ticket. That is, if the status is "in review" for one of the > releases, it's "In review" for all of them, even if the actual fix > hasn't been checked in on another branch. > * We may wish to create bugfix releases to an already created heartbeat > release. > > I suggest the following approach: > * Create Jira releases for the source code release simply by date: > fineract.2018.02, fineract.2018.04, fineract.2018.06, etc. > * Postfix the release if a bugfix release is necessary: > fineract.2018.02.r2. > * Create jira releases in Jira for each maven artifact as well: > portfolio.1.0.0, portfolio.1.1.0, deposit.1.0.0, deposit 2.0.0, etc. > * Add an upcoming fixed version to a ticket only after it's done-done > for that version. That means developed, tested, and merged. Create a > new Jira field "Targeted version" for the purpose of communication. > > Do you believe this is a workable approach? Did I miss anything? > > Best Regards, > Myrle >
