Ability to bundle features / bugfixes in common release branch

[bferguso]

Some issues are very small in scope, and as such I don't feel they need to have their own set deployments. Currently the pull request always checks out from master branch, but there should be an ability to checkout / checkin from a common release branch so a deployment can happen at the release branch level not feature/bugfix level.

[cvarjao]

@bferguso , the checkout is from the branch behind an issue. Whether than is short lived (feature) or more long lived (release/RFD, EPIC issue) is up to you. can you provide an example/scenario?

[bferguso]

@cvarjao Suppose I have a number of small fixes - one is a typo, another one is a wording change and a third one is a layout issue, each with a Jira ticket# (say J-1, J-2, and J-3). I don't want to do a promotion of each individual change (ie one promotion per Jira ticket), I want to do a promotion with all three changes in it.

Currently the behaviour I'm seeing is on checkout it takes a branch from master for each one: master -> feature/J-1 master -> feature/J-2 master -> feature/J-3

When performing a backlog:checkin it creates 3 pull requests: feature/J-1 -> release/J-1 feature/J-2 -> release/J-2 feature/J-3 -> release/J-3

From my understanding if I want to do a build (now currently in Jenkins) then I have to :

1. Perform my feature/bugfix checkouts associated with that RFC (release/1.0.1 -> feature/J-1, feature/J-2, feature/J-3
2. When checking back in, the pull requests created are feature/J-1 -> release/J-1, feature/J-2 -> release/J-2, etc.
3. Create a release branch, say master -> release/1.0.1
4. Manually create (or modify the existing) 3 pull requests: (feature/J-1 -> release/1.0.1, feature/J-2 -> release/1.0.1, feature/J-3 -> release/1.0.1)
5. merge the 3 pull requests created in (2)
6. perform a Jenkins (or whatever mechanism) build of branch release/1.0.1 and deployment of that branch.

What I would like to be able to do is:

1. Create my RFC branch (master -> release/1.0.1)
2. Perform my feature/bugfix checkouts associated with that RFC (release/1.0.1 -> feature/J-1, feature/J-2, feature/J-3)
3. When checking back in, the pull requests created are feature/J-1 -> release/1.0.1, feature/J-2 -> release/1.0.1, etc.
4. Merge the pull requests automatically created in (3)
5. Perform build/deployments of release/1.0.1

This has the advantage of: a) Reducing the amount of manual Stash work (eliminates #4 in the first scenario) b) Picking up changes made in subsequent checkouts if desired (depending on when the merges back to the RFC branch are done) which can reduce the number of merge collisions c) Handling merge collisions earlier if previous merges back into the release branch have been performed.

Maybe you have a different pattern in mind, but the above seems like a lot of admin work, especially for smaller feature/bugfixes which might be part of a bundled release.

[cvarjao]

That is the intention, the RFC branch (aka release branch) should be the one pooling features

[cghobson]

There's a slight error in the behaviour you've diagrammed above, regarding release/J-1, release/J-2, and release/J-3.

IRS-383 is an RFD subtask; I did a backlog:checkout and made branch IRS-383. I added a (spurious) commit, and backlog:checking created a merge request from feature/IRS-383 to release/IRS-215. IRS-215 is the RFC that 383's RFD is linked to, fixing version 4.0.0 . I duplicated IRS-383 as IRS-390 and repeated these steps; the branch feature/IRS-390 is forked from release/IRS-215 as well.

So the behaviour you're looking for is presently possible. It requires the bugfixes (feature branch) to be downstream of an RFC (release branch) in Jira. If you were to create three standalone Issues (or three RFCs) for the bug fixes, they would each be their own release.

If I've misinterpreted your requirements here, please reopen the ticket and let me know!