git workflows: how to integrate and test feature branches without continuous delivery?

Question

I like the "github flow" workflow described by Scott Chacon very much: http://scottchacon.com/2011/08/31/github-flow.html

He describes why github does not use the git flow workflow described by Vincent Driessen (http://nvie.com/posts/a-successful-git-branching-model/), and we don't use it for the same reasons, where the most important reasons are, that it does not work well with pull requests and it does not fit well to website development where you don't have "officially released versions of a software product" but continuously improve the website.

We are developing a large online community in a small team with a lot of old legacy code (some code is more than 10 years old) with bad test coverage. We are using a similar workflow as github, currently we use feature branches for developing, and use pull requests to integrate them into the master branch, do peer reviews, ask for feedback etc. When the feature has been finished and approved by others, it's merged into master. A few times a week we push master to a staging enviroment which is used by our testers, as well as beta users. We try to release the master branch to public every two weeks, so every feature branch which gets merged has to be tested good enough and "more risky feature branches" are not merged in the last few days, until the release to public is done.

Thats not a perfect workflow, because when merging of "risky features" to master starts again, we can't use master to deploy hotfixes to public anymore.

Github uses continuous delivery for deployment, which is not an option for us, we do need people to test a feature before we can release it to public.

A pull request can only be merged into one branch. So it's a straightforward workflow at github with only one long running branch which is master. Perhaps we should not release every two weeks, but release pull requests when they are merged to master? But that way it's hard to test, we could run the unit-tests we have on the feature branch before it is merged, and we could deploy the branch to staging for beta testers, but that's not always that easy, sometimes you have to do database changes manually (we can't do it automatically, it's too risky because our staging server for beta testers uses the production database), so you have to wait until this is done by admins. And the bigger problem is, if you release only feature branches to the beta users, they are not integrated, they will see new features, and features getting removed perhaps multiple times a day. Not to say that you cannot run integration tests, or you have run them very late just before release, when a feature branch is just merged to master...

On the other hand, if we use 2 long running branches like develop and master as described in git-flow, we can solve the hotfix problem, we could use pull-requests to merge feature branches to develop, we could use a pull request for a release branch for merging recent changes into master, but we can't merge back changes to develop using the pull request workflow.

As you can see in the github flow article (#6 – deploy immediately after review), github engineers can deploy not only to production, but also to a staging environment. And not only engineers can do that, but also support and designers. But how does it work with only one integration branch? You don't need a staging environment if the last pull request is going to production anyway in a few hours or minutes. Sometimes they seem to deploy feature branches to staging, that makes sense, but they are not integrated, so what I described above will happen, you see features coming and going in your staging environment, even if they merge changes from master before deploying a feature-branch to staging (do you think this would be a good idea?). Or does it make sense to have multiple staging environments, one for every feature branch? But this way again you loose advantages from continuous integration. And as said, I don't think you can do this in a beta testing environment.

I see problems in both workflows, git flow and github flow, I like github flow better, but it seems difficult if you don't have a good test coverage and need more testing by people.

So, how can I integrate and test feature branches, when they need more testing by people (qa and beta testers)?

Answer 1

You can have several branch heads run along one common integration branch :

 ----A---B---C---D---E---F---G---H---I
              \           \           \
               goodToGo    testing     toBeTested