5 ms·

The branching model that I use with my team projects used to be like this - master was always production code, development was always code ready for QA, and fea

by Eclyps 12y ago

The branching model that I use with my team projects used to be like this - master was always production code, development was always code ready for QA, and features would be branched off and development. It worked great for larger projects that had releases that were weeks apart, but a lot of our projects are very small and may have several minor changes go to production in a short amount of time. We decided to kill our development branch and just create feature branches off of master. If multiple devs are working on the same project scheduled for the same release, we will create a release branch and they can branch features off of that. An open pull request into master is how we initiate the QA process, and all remediations are discussed in there. When the pull request is merged and closed, we all get an email so we know to update our local code. It's been working really well so far for both our small and large projects.

jipiboily 12y ago
Just an FYI, with this model, we still do multiple deploys each and every day :) There might be a point where this won't work for us anymore, it's always time to change. Also, this is not because a branching model works for a team that it will for all teams and projects. Like any in-house, process the branching model will evolve with the team and it's requirements to be efficient.
- Eclyps 12y ago
  We ran into a couple issues (none of them significant) 1. When someone merges their branch into development for QA, it's going to be there (with or without issues) for anyone else who merges for QA after that. If the first merge has bigger issues than expected, it's a bit of a pain to roll it back and re-merge the later branch. Without the development branch as a base for our QA, we just QA things one feature/release branch at a time. This lets us easily send back branches that aren't ready for production and move on to a different branch that is before any merging takes place. 2. We weren't sure how to handle pull requests with the development branch always being there. We used to set development as our "default" branch in github, so any pull requests would be automatically merged into there. That got a bit confusing, though, as most of us were so used to merged pull requests representing a change that has already been reviewed and accepted as production-ready. And as for the merge to master, should we submit another pull request? It just seemed like an unnecessary extra step in a lot of situations. But you are absolutely right. Different flows work for different teams and projects. I'm sure as our team evolves, so will our workflow.
  - jipiboily 12y ago
    For #1, we use Fourchette (https://github.com/jipiboily/fourchette https://github.com/jipiboily/fourchette), which means we have a Heroku fork of our QA env for each GitHub PR. For merges to master, we submit other pull requests that we call "Release: ...". We can then see if CI and Rainforest tests are passing, if all is green, then we merge! :)

by Eclyps 12y ago

jipiboily 12y ago

Just an FYI, with this model, we still do multiple deploys each and every day :) There might be a point where this won't work for us anymore, it's always time to change. Also, this is not because a branching model works for a team that it will for all teams and projects. Like any in-house, process the branching model will evolve with the team and it's requirements to be efficient.

Eclyps 12y ago
We ran into a couple issues (none of them significant) 1. When someone merges their branch into development for QA, it's going to be there (with or without issues) for anyone else who merges for QA after that. If the first merge has bigger issues than expected, it's a bit of a pain to roll it back and re-merge the later branch. Without the development branch as a base for our QA, we just QA things one feature/release branch at a time. This lets us easily send back branches that aren't ready for production and move on to a different branch that is before any merging takes place. 2. We weren't sure how to handle pull requests with the development branch always being there. We used to set development as our "default" branch in github, so any pull requests would be automatically merged into there. That got a bit confusing, though, as most of us were so used to merged pull requests representing a change that has already been reviewed and accepted as production-ready. And as for the merge to master, should we submit another pull request? It just seemed like an unnecessary extra step in a lot of situations. But you are absolutely right. Different flows work for different teams and projects. I'm sure as our team evolves, so will our workflow.
- jipiboily 12y ago
  For #1, we use Fourchette (https://github.com/jipiboily/fourchette https://github.com/jipiboily/fourchette), which means we have a Heroku fork of our QA env for each GitHub PR. For merges to master, we submit other pull requests that we call "Release: ...". We can then see if CI and Rainforest tests are passing, if all is green, then we merge! :)