2014-12-01 21:42 GMT+01:00 Matt Coleman <[email protected]>: > Our developers work on feature branches, branched from master. When they > think it's ready, they notify QA. On a two week cycle, QA selects a set of > feature branches to target for inclusion in master. They test the features > individually, then merge them to a temporary branch and run tests to verify > that the branches didn't have any conflicting changes. If they discover > bugs in a certain feature that are too complex to be fixed within the > release cycle, it will be sent back to the developer and pushed back to a > later release. Tagged commits on the master branch get automatically built > and uploaded to our package servers. The distinction between development, > beta, and production releases is handled outside of version control: > separate package repositories are used to distribute software to the > development, beta, and production fleets of machines. If a hotfix needs to > be made for a production release and new development versions have been > released, then we branch off of the produ > ction releases tagged commit, fix the problem in the branch, and tag the > branch to release it. >
This sounds like a very useful workflow. However, I think it is depending on team size. It obviously works well for you as a large team. But now consider rsyslog. Almost all of our "dev teams" (90+ %) have a single member: me ;) The QA team also has a single member: me. So guess now how hard it is for me to think about what step to take next. Also, I usually work on a single feature branch (for new features), which I merge when done (and put my QA hat on). It doesn't really make so much sense to work on different feature branches, except for bugfix-like things or an occasional feature branch which needs to be stopped working on for some reason or another. With the new scheduled release cycle, I glance of what I can finish until roughly a week before release date and will add that, therafter only occasional bugfixes (which are unlikely to happen, as I do no longer work on that code base). What would be really useful, but is no longer present like 4, 5 years ago, is folks who try out features before they reach the stable branch. We mitigate this as good as we can with improvements to the testbench, but nothing beats the real testers and their large number of different configurations. I just thought I should clarify this point. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
