So here's the scenario:
We've been developing this application for almost a year now. The application is already on production and we have:
- 3 Developers
- 2 QA guys
- 1 Team Lead (me)
We have worked through several workflows, some have worked better than the others, my simplest approach has been to do rolling releases as it involves less work from the developers and since we don't have a release manager (and I have to to a lot of other chores besides merging) the resources are scarce, that being said, my (horrible) workflow lately has been:
- 2 branches:
- All branches are made from
developmentbranch is free-for-all; everyone gets to merge there without pull requests whatsoever, for integration purposes
- When Developer A feels his feature is ready he makes a pull request against
- Developer A then assigns the PR to Developer B for code review
- If code review goes well, Developer B assigns the PR to QA guy
- QA guy tests and if everything goes well, it goes to
master, PR gets merged
- Customer goes to a staging server that is deployed when anything gets merged into
masterand if every feature tested is ok then we are free to (manually) deploy to production, these deployments are made manually
As you can guess the problem with this approach is that if the customer does not accept a feature (hence, there is a blocker) once it has been merged to
master it means that we cannot ship to production anything, even if there were a bunch of other features which worked well.
Lately, our CTO has requested me to use gitflow and while I found it good and organized I can't seem to fit it in our development process. Here's what the customer wants:
- Have a
developmentenvironment that could be broken but shows progress on currently working features
- Have a
stagingor QA environment where feature-ready code is to be tested by both QA and the customer itself
- Have the ability to ship "features not environments" (quoting my CTO)
So I'm kinda lost on this, where and how should the testing happens? Cannot be done on
development since it'll have unfinished features, probably broken code, we could do it on a QA environment or staging but then again, if they want to be able to cherry-pick features to deploy to production, and QA already has, say 3 features, how would you do that? More importantly, where does QA / Testing happens?
As said before, the CTO recommends gitflow, yet they want testing happening and release of isolated features instead of scheduled releases (where you do code freeze) I don't seem to get it, I have read several posts on SO but maybe I'm missing something.
So, in summary:
- Where does qa/testing happens in gitflow?
- Is it possible to do feature-push instead of release-pushes to PROD?