问题
I have a few questions around how do you handle testing and deployment when many developers are working on the same thing (that cant be split further) and you still want to deploy daily.
Currently we follow Gitflow where we have our features branches that everyone is working on an isolated feature. Features are merged into develop branch. Every now and then we take some time to cater for user requirements / bug fixes / quick features etc.
The end goal is to get those to PROD asap. My question is what process would you suggest such that:
1) We can deploy without introducing bureaucracy (e.g. Release on the last Friday of every month).
2) If someone commits code that is introducing a bug it doesn't affect someone else that has committed bugless code. In other words, if Coder A tries to fix a bug by introducing a new bug, and coder B has fixed his bug then coder's B code will get further into the pipeline while coder A will stay late fixing the bug :)
3) We cannot have unlimited testing environments. We also don't want to spend our day setting up testing environments. We need a solution that can work around this requirements (so test on feature branches is not an option unless I m missing something)
3) The testers know exactly without a doubt what they are approving to go into prod.
Btw we have a fairly extensive set of unit / functional tests but this question is about the process so those are not really relevant.
Also, I have researched all the other questions and nothing really addresses all of my questions. If you think there is one that does I would be happy to have a look.
Thanks
回答1:
Process wise you need only one more optional step compared to the "standard process": If you find a bug (or probably a critical bug) you roll back all changes (i.e. merges, which contain the bug).
Here is how it works:
create a Branch Under Test, or BUT for short, from the development branch
feature branches get merged into the test branch, not directly into the development branch
you have a BUT which is right now either identical to the last release or well tested from the last iteration of this process.
Now you merge all the feature branches /bugfixes in that branch that you have ready.
you test it. If a critical issue arises, i.e. one which makes the feature/bugfix which contains the bug undesirable for the next release, you undo the merge of that feature by resetting, and redoing all merges or by rebasing, and removing the commit, which is basically the same. Note that this changes the history of the branch, so nobody should merge this branch into anything before testing is completed.
if a test iteration completeted successfully (i.e. without major bugs) you merge it into development.
Lets check how this fulfills your requirements:
We can deploy without introducing bureaucracy (e.g. Release on the last Friday of every month).
You still have your release branches as before. No problem here. The only overhead is that you might have to undo merges, if they are to buggy, but I don't see a way around that.
If someone commits code that is introducing a bug it doesn't affect someone else that has committed bugless code. In other words, if Coder A tries to fix a bug by introducing a new bug, and coder B has fixed his bug then coder's B code will get further into the pipeline while coder A will stay late fixing the bug
Check
We cannot have unlimited testing environments. We also don't want to spend our day setting up testing environments. We need a solution that can work around this requirements (so test on feature branches is not an option unless I m missing something)
You only need one testing environment. More might be helpful to facilitate parallel work of multiple testers. But that is optional.
The testers know exactly without a doubt what they are approving to go into prod.
You can very easily determine with standard git commands if a feature branch is part of the history of the BUT, which is what you need.
Drawback / Things you need
Nothing goes into production, or can be merged with other peoples work as long as it isn't approved by the testers. This can become a bottleneck in the process, especially if the stuff that comes from the feature branches is low quality. If testers have to unmerge stuff they'll have to retest the rest (at least testers I know would insist on that, and for a good reason). So bugs slow you down (which isn't new, but becomes very obvious with such a process).
To limit this effect you should put a lot of effort to make the feature branches as good as possible:
- run automatic tests of the feature branch before merging with BUT
- run automatic tests of the feature branch after merging with BUT
- have lots of GOOD automated tests.
- code reviews
- pair programming
- automate the deployment in your test environment
Basically everything that reduces the amount of work the testers have to do and speeds up the rest will help a lot.
You said you can't have many test environments. Consider if you can have partial test environments, which don't require all the resources, but are still good for some of the tests.
来源：https://stackoverflow.com/questions/34989588/gitflow-and-testing-deployment