1

I'm looking for suggestions on how to modernise my development/release practices by potentially introducing some automation. I'll outline the current process to help explain why I'm currently struggling.

We have 2 long life branches, master and staging. Live servers point to the master branch and our test/staging servers point to the staging branch.

We have 2 different types of short life branches, fix/ and feature/. We label our branches fix/X and feature/X depending on whether it's a bug or a story being developed, where X is the id of the relevant ticket. These short life branches are only ever created from master, never from staging.

When a developer has finished working on their branch, it tested in isolation locally and then peer reviewed by another developer. Once it has passed peer review, it is merged into the staging branch which is then pulled on to the staging servers. Once it has moved into the staging branch it is then tested by a QA.

Releases are scheduled by a product manager for particular dates so that we're able to compile release notes and update customers before changes are made. To release, I spend a considerable amount of time opening each ticket, merging the fix/feature branch into master, before running a pull on each of the live servers.

If during testing, a problem is found with one of the features/fixes, we use GitHub to revert the pull request and remove the offending code from the staging branch.

Earlier I mentioned that we only create branches using master as a base, never from staging. This is because we merge un-tested code into staging for it to be tested alongside other fixes/features. So if we were to merge feature/A into staging, then branch from staging to work on fix/B, to later realise feature/A was not working correctly then we would also have to remove the code in feature/A from fix/B*. This then means that releases of 20+ tickets involve a lot of time spent merging individual branches into the master branch, rather than just merging staging into master.

I've looked into different flows and CICD applications etc, but I'm struggling to see how to implement them into our current process without completely altering the way we work.

The main pitfall that I'm looking to overcome is having to manually merge an entire release worth of branches (often in the 20's) into master on release day. It's time consuming and often-times conflict ridden.

Improve this question
1
  • Multiple questions: 1) You mentioning multiple features per release. Are those features also part of an epic and is the epic assigned to a specific team? 2) How often does it happen, that features are affecting each other? In such cases are the features in related components or unrelated ones? 3) You are having automated tests for each of the features and fixes?
    – Cwt
    Commented Jun 17, 2022 at 21:52

1 Answer 1

Reset to default
4

By merging your feature/fix branches separately to staging and master, you are very likely releasing on master combinations of features & fixes that were never tested by QA in that combination. That means that in effect you are releasing untested code.

To overcome that, you should actually be merging from staging to master on release day.

If that is not feasible, for example because QA takes 2 days and you don't want to force a code-freeze on staging in the days before a release, you can introduce a new (short lived) branch type: a release branch.

On 'release_day - X' you create a release branch off staging. This release branch gets a final testing round from QA and if they say it is good, the branch gets merged to master. (that is actually how gitflow works, if your staging branch would be called develop.)

If you want to release a set of features/bugs other than what is present on staging, then you could create a release branch off master and merge features/bugs into there as they become scheduled for the release and QA has verified them on staging. Once the feature set is completed, QA can do a round of testing on the release branch to ensure no needed fixes were missed.

If QA finds issues when testing the release branch, you can make the necessary changes on the release branch itself and merge is also back to staging.

Improve this answer
2
  • My only problem with both of those solutions is the fact that for release X we will have a specific set of completed tickets scheduled, where staging has everything that has been tested as well as what is currently being tested. So whether we branch off of staging, or merge staging into master, we're still going to be pushing partially tested/non-scheduled tickets in as part of the release. I think part of the problem is that QA's use staging in order to complete their testing. I've been wondering whether we need to introduce another long life branch and server for testing?
    – Mike Pearson
    Commented Jun 16, 2022 at 14:19
  • 2
    @MikePearson, My proposal should not allow partially tested work to be released. Then you are not freezing your release early enough (either on the staging or the release branch). I added a paragraph how you could work if not everything on staging should be scheduled for the release.
    – Bart van Ingen Schenau
    Commented Jun 16, 2022 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.