1

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: development and master
  • All branches are made from master
  • development branch 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 master
  • 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 master and 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:

  1. Have a development environment that could be broken but shows progress on currently working features
  2. Have a staging or QA environment where feature-ready code is to be tested by both QA and the customer itself
  3. 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?

closed as off-topic by Todd A. Jacobs, Mark Phillips Jun 15 '15 at 23:27

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Software engineering questions are off-topic here, but can be asked on Programmers Stack Exchange." – Todd A. Jacobs, Mark Phillips
If this question can be reworded to fit the rules in the help center, please edit the question.

2

I think that you can use the Gitflow as described http://nvie.com/posts/a-successful-git-branching-model/ and satisfy the need to “cherry-pick features to deploy”. Here is how your workflow could look like:

  • In addition to the master and development branches, you need to create separate branch for each feature you may potentially release independently.

  • To make sure that each feature is kept separate until it is accepted by customer to be released, you need to only merge the feature branches back into the development and master branches after successful QA and customer acceptance.

Please note that a drawback of this approach is that each of your feature branches would exist separately and would not be merged together potentially for a long period of time. This would make the merge process difficult as a lot of changes would accumulate over time and potentially create a lot of conflicts to resolve.

Also any features and bug fixes, released after the current feature branch had been created, would need to be merged into the current feature branch before it can be released, which could create extra work.

So you need to make sure to keep the time between the start of a new feature branch and the release, or cancellation, of the feature branch as short as possible and limit the number of features that you will be working on at any one time.

“Where does qa/testing happens in gitflow?” Testing should be done throughout development rather than all at the end. Since you need to complete the QA and customer acceptance testing before deciding whether the feature would be released, you need to do this step on the release branch before it is merged into master and development.

The ramming decision is whether to merge in all released features into the current feature branch before QA and customer acceptance or only after the feature is accepted. The answer to this will depend on whether the customer is ok with verifying the feature without merging in all released changes and how much work is involved. I would probably opt in for merging in released changes into all working feature branches as soon as possible, to keep these branches as close to master as possible.

0

Have you explored using feature toggles instead of relying on branching? With feature toggles in your code you can turn on/off specific features and actually ship features to production that are turned off because they are defective while shipping other features the customer has deemed OK to turn on. You only ship one code-base and eliminate the need for feature-based branches.

With toggles you can turn on/off a feature in production and bypass the rest of your pipeline as well...this is great for customers' who's release plans don't always align with what the delivery team can put out.

There are several frameworks available but also challenges with this approach: -If you use automated testing you need to be able to toggle on/off certain tests depending on features that are on/off -Figuring out where to insert a toggle isn't always straight forward. -Inserting toggles and learning how to use a framework take time and increase development complexity

  • I like the approach, although I feel requires lots of discipline and control so you really know that some half-baked feature, even when toggled off won't break anything currently workin – Gustavo Rubio Jun 12 '15 at 21:57
  • You still need branches if you use feature switching. A: you shouldnt ship unfinished features, even turned off and B you should still branch for units of work – Ewan Jun 20 '15 at 21:59

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