4

I am new to git and understand a little bit about Git.
My company is currently have 1 program and the program divides into 5 products. each product is handling by different team.

Currently my company git have 5 branches such as :

  • dev = this branch is for developer to build program (dev.program.com)
  • test(alpha) = this branch is for tester to test the program (test.program.com)
  • staging(beta) = this branch is for tester test the program (double check of error ) and client test the program. (stg.program.com)
  • staging-trx = the duplicate of staging and for developer to make sure that no error conflict while cherry pick from staging before it is served to production. (stg-trx.program.com)
  • master = merge from staging-trx and ready for production (master.program.com)

This is our work flow.

  1. developer finish building a program, the developer will commit and push the files into test branch then tester will do stress test into test environment.
  2. after testers are finishing the stress test, developer do pull, cherry pick the committed file from test branch and push into staging branch. after that, tester will do flash test.
  3. after testers are finishing the flash test, developer do pull, cherry pick the committed file from staging branch and push into staging-trx branch, after that developer will merge the staging-trx into master branch.

But I have some problems.

Let say in one team have 2 developers (Andy and Robert) and responsible for product A.

  • Robert is handling for new feature and bug fixed
  • Andy is handling bugs fixed

Currently Robert is still building a new feature and that new feature will affect some files and major changes to the code. so Andy cannot do any revision of code to fix the bug because almost all of code has changed.

If I created new branch for every new feature, the tester would find it difficult to test, moreover there would be more websites to be created only for new feature. this means that not only for product A, but there are another products will face the same problem.

So, is there any solution for this case?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Baba Carita
  • 95
  • 7

1 Answers1

3

This is typically what gitworkflow address

gitworkflow

Instead of merging A to B, B to C, C to D and so on, you only merge feature branches.

Each developer (or group of developers) works on a feature branch and merge it to dev for integration testing.

But when it comes to merge to additional development lifecycle step (test in your case, then staging, qa, any name you want), you do not merge dev to test

You merge the selected feature branches (that were initially merged to dev) to the branch you want (test, staging, etc)

That way, you only select the subset of features that you deem ready and working together, as opposed as trying to revert the "not ready" features from dev, and then merging dev to test.

I detail that model further here and illustrate it here

One important point: the dev branch (for integrating feature branches together) is transient: it is created/destroyed for each new release (as opposed to one fixed eternal dev branch merged to master from time to time).

You recreate as many integration branches you need to testing features together (dev, test, staging, and so on).
Then, when ready, you only merge the right feature branches to master (or any other release branch), delete your dev branch, and recreate it for the next release.

So to repeat:

The feature branch is merged multiple times:

  • one time to dev for initial integration testing,
  • then the same feature branch is merged again in test directly (where a second build can occur, you don't have to rebuild in feature),
  • then merged again directly in staging (each time because that feature branch is deemed ready to advance to the next lifecycle development stage)

You do not cherry picking from (for instance) test to staging.
You merge the feature branch which has pass the test to the next step in your integration lifecycle (merge feature to the staging branch)

Currently Robert is still building a new feature and that new feature will affect some files and major changes to the code.
So Andy cannot do any revision of code to fix the bug because almost all of code has changed.

Yes, Andy can, in an hotfix branch, dedicated to maintain the latest code released into production.
Both Robert and Andy can participate in that branch, and they will be responsible to apply their fix commits to dev if said fix is needed there (since the code has change, maybe that bug fix is no longer relevant in dev)

does Andy will merge from hot branch to test? because our final step is test => staging => staging trx => master

The all point of this answer is to illustrate you don't have to merge from A to B to C.
For the hotfix branch, you rarely merge it back anywhere else, since the dev or test branches have code which has evolved considerably since the last release. You only cherry-pick the fix commits you need back to dev or test.

After the feature has been already in production environment, I will destroy that feature branch right?

Well... yes, "destroying" the feature branch will remove the pointer to that branch.
But the actual commits which were part of said branch will still be visible from the merge commit done on master. That is OK, and can be useful to debug that feature later on: instead of the big final merge commit, you can later check the commits from the second parent of said merge commit: they are the commits from the old feature branch.

While the new feature A branch is already in test branch, and tester are still doing stress test to the new feature A, there is bugs in production and Andy will fix the feature B bug in hotfix branch.

The question is, after Andy has fixed the bug in hotfix branch, then where should Andy merge the current hotfix branch?
Because when if there were bugs, and developer has fixed the bug, it would not go directly to production, tester will do test first to check the bug is already really fixed or not.

You would need a second test branch dedicated for testing hotfixes (I would do those test directly on hotfix though) and then merge back to master, to update the production.
The point is: when you identify a parallel development effort (as in "testing feature branches" and "testing an hotfix"), separate branches are required.

But again, for bug fixes, that is typical of an "emergency path" for which you have a shorter branch workflow and a dedicated test-hotfix branch (name it as you want) for that type of scenario.

The other approach is simply to reset the test branch, and merge back only the branches you need urgently (feature B in this case): test, the merge B to staging etc... all the way to master.
Finally, once B is ready, you can use the same test branch to add (merge) feature A back in, and continue your test on A in an environment where B has already been validated.

The drawback of resetting test is that it blocks all other development integration though.
That is why a dedicated branch for this is preferable.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • `Each developer (or group of developers) works on a feature branch and merge it to dev for integration testing` => does it mean that each developer have different environment when building scripts, then if developers want to test out the coding, it should merge to dev first, so developer can do a test? if yes, it will be difficult for developer to build program, because after they write scripts, they have to merge the scripts first to dev and then do testing. – Baba Carita Jun 12 '19 at 06:42
  • @BabaCarita That step (merge feature to dev) can be automated: push to a dedicated CI (Continuous Integration) system (Jenkins or any other): it will tell you if: a/ it compiles b/ it can be merged to dev without conflict c/ if the merged feature compiles d/ if the tests passes. The all "continuous integration" is there to automate the all process, allowing a full test suite (in dev) everytime a new commit is pushed to a feature branch! – VonC Jun 12 '19 at 06:46
  • `But when it comes to merge to additional development lifecycle step (test in your case, then staging, qa, any name you want), you do not merge dev to test You merge the selected feature branches (that were initially merged to dev) to the branch you want (test, staging, etc)` => can you explain this? i don't get what you mean about this one. but from my perception, does it after the feature already in dev and commit to test, and it comes to additional development after test, i build again in feature branch, and then merge to test directly? – Baba Carita Jun 12 '19 at 06:47
  • @BabaCarita Yes, the feature branch is merged multiple times: one to dev for initial integration testing, then the same feature branch is merged again in test directly (where a second build can occur, you don't have to rebuild in feature), then merged again directly in staging (each time because that feaure branch is deemed ready to advance to the next lifecycle development stage) – VonC Jun 12 '19 at 06:49
  • `(where a second build can occur, you don't have to rebuild in feature)` => what do you mean of I don't have to rebuild in feature? – Baba Carita Jun 12 '19 at 07:14
  • `That step (merge feature to dev) can be automated: push to a dedicated CI (Continuous Integration) system (Jenkins or any other)` => I think this step, from our current workflow, if it were not a major changes when build new feature, we just do stage line or stage hunk to the code change.. so I don't have to create feature branch. the problem is only when major change occurred. – Baba Carita Jun 12 '19 at 07:18
  • @BabaCarita On the second build part, if your feature branch was already built in dev (successfully), the only build that is of interest is the same feature branch merged in test: build there. – VonC Jun 12 '19 at 07:22
  • @BabaCarita " we just do stage line or stage hunk to the code change": that sounds like developing directly in dev. The problem is to manage all those little changes, reverting some that are problematic while keeping others. – VonC Jun 12 '19 at 07:24
  • `Yes, Andy can, in an hotfix branch` => does Andy will merge from hot branch to test? because our final step is test => staging => staging trx => master – Baba Carita Jun 12 '19 at 07:29
  • @BabaCarita The all point of this answer is to illustrate you don't have to merge from A to B to C. For the `hotfix` branch, you rarely merge it back anywhere else, since the `dev` or `test` branches have code which has evolved considerably since the last release. You only [cherry-pick](https://stackoverflow.com/a/1994491/6309) the fix commits you need back to `dev` or `test`. – VonC Jun 12 '19 at 07:33
  • `On the second build part, if your feature branch was already built in dev (successfully), the only build that is of interest is the same feature branch merged in test: build there.` => after the tester already finished testing, and go to next step staging, could I just cherry picking from test to staging (our current workflow)? because if I skip our current workflow then like you said, for the next project it should be current feature directly to each branch and then after the feature has been already in production environment, I will destroy that feature branch right? – Baba Carita Jun 12 '19 at 07:37
  • `The all point of this answer is to illustrate you don't have to merge from A to B to C` => okay i got you meant and just skip above question about my current workflow.. – Baba Carita Jun 12 '19 at 07:39
  • @BabaCarita Yes, you don't cherry picking from test to staging indeed. You merge the feature branch which has pass the test to the next step in your integration lifecycle (merge to the staging branch) – VonC Jun 12 '19 at 07:43
  • @BabaCarita "after the feature has been already in production environment, I will destroy that feature branch right?" Well... yes, "destoying" the feature branch will remove the pointer to that branch. But the actual commits which were part of said branch will still be visible from the merge commit done on `master`. That is OK, and can be useful to debug that feature later on: instead of the big final merge commit, you can later check the commits from the second parent of said merge commits: they are the one from the old feature branch. – VonC Jun 12 '19 at 07:45
  • while the `new feature` branch is already in test branch, and tester are still doing stress test to the new feature, there is bugs in production and Andy will fix the bug in `hotfixed` branch, the question is, after andy has fixed the bug in `hotfix` branch, then where should andy merge the current `hotfixed` branch? because when if there were bugs, and developer has fixed the bug, it would not go directly to production, tester will do test first to check the bug is already really fixed or not. – Baba Carita Jun 12 '19 at 07:55
  • @BabaCarita Then you need a second test branch dedicated for testing hotfixes (I would do those test directly on hotfix though) and then merge back to master, to update the production. The point is: when you identify a *parallel* development effort (as in "testing feature branches" and "testing an hotfix"), separate branches are required. – VonC Jun 12 '19 at 07:57
  • the scenario is test has already do a major change to the code because of new feature. let say the bug is a feature too, and now there is feature A and B.. because feature A is requested first (a major change) and already in test, then feature B (latest code from production) must be tested and ready in production in that day.. so if i merge feature B to the test branch, it would be conflict.. – Baba Carita Jun 12 '19 at 07:59
  • @BabaCarita "Then feature B (latest code from production) must be tested and ready in production in that day": again, that is why test cannot be the unique validation/integration branches. "ready in production in that day" that is typical of an "emergency path" for which you have a shorter branch workflow and a dedicated (as I mentioned in my last comment) test2 (name it as you want) for that type of scenario. – VonC Jun 12 '19 at 08:02
  • @BabaCarita The other approach is simply to reset the test branch, and merge back only the branches you need urgently (B in this case): test, the merge B to staging etc... all the way to master. Finally, once B is ready, you can use the same test branch to add (merge) feature A, and continue your test on A in an environment where B has already been validated. – VonC Jun 12 '19 at 08:04
  • well, i got what you meant now and it's really useful and something new for me.. but i can't accept your answer as solved answer, because i must try it out first and after it has already solved my problem, I will accept it as solved answer. thanks for your time man! you are awesome! – Baba Carita Jun 12 '19 at 08:12
  • @BabaCarita You are most welcome. Feel free to test that approach, but consider asking a new question instead of comments if that test yields any issue. – VonC Jun 12 '19 at 08:14