Clever Geek Handbook

Git flow and multiple wait functions QA

We have been following a git stream that has been running for the past few months now, but has had issues with long QA wait times.

Here's our process:

  • developers develop locally on feature branches
  • when the team thinks the function is ready it merged into dev, clicked on dev server (Codeship and rsync)
  • customer approves the feature
  • merged with master, clicked on prod

Unfortunately, it can take up to several weeks for a customer to approve a feature. This could be due to backlog, content creation, staff turnover, etc.

However, at the same time, a new feature can be merged into dev and pushed to the dev server for approval. Say that this 2nd feature is approved and should be rolled out as soon as possible (possibly). How can I get this 2nd function from dev without bringing the 1st function?

+3


source to share


2 answers


How do I get this 2nd function from dev

without casting the first function?

You will not. But once dev

merged into master

, you can return the 1st function committing from master

to record that the 1st function has not yet been approved.

This is safer than cherry-picking commits from the second function, as it duplicates those commits from dev

to master

and makes the future merge more complex.

If this is repeated frequently, the workflow will not adapt to the current development process.



If it would be better if:

  • You have a branch integration

    where you merge any feature that gets approved (on the dev server).
  • dev

    should have been updated with only approved features from the feature branch (on the dev server).

In other words, you are merging the feature branch twice:

  • once in integration

    for formal customer review and function approval
  • once in dev

    , with a second (and faster) client checkout to see if the feature still works (how it doesn't bundle in the same codebase as the integration)

In dev

you will resume your normal release management process (by clicking prod

)

+2


source


It's not "git-flowy" enough. The development department should only contain those functions that have received their permission - therefore the HEAD in development should only contain those codes that have been tested and are ready for release for mastering / production.
The git-flow solution to your problem is that when you finish working on a function, you load it to its original position (push the function) and send it to the tester (client?). Only when approved will it be merged for development.

The function must be independent of each other, so the client can test each separately according to his own schedule (*). In your flow, you may have good code and bad code combined together, and the test result will not help you identify the source of the problem.



*), only if it isn't, or if you want to test a parallel function, use the integration branch.

0


source






More articles:


All Articles