{"thread":{"id":"26733","subject":"Git workflow for beta/production","startedAt":"2011-03-14T22:27:22Z","lastAt":"2011-03-15T12:10:33Z","messageCount":4,"participants":["Joseph Huttner","Junio C Hamano","Randal L. Schwartz","Drew Northup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"163351","messageId":"324BE2A8-5987-4324-AE27-D5CC01341710@appnexus.com","threadId":"26733","inReplyTo":null,"subject":"Git workflow for beta/production","fromName":"Joseph Huttner","fromEmail":"jhuttner@appnexus.com","sentAt":"2011-03-14T22:27:22Z","receivedAt":"2011-03-14T22:27:22Z","isPatch":false,"sender":{"key":"jhuttner@appnexus.com","avatar":null},"body":"I am in search of a new Git workflow.  Previously, my team was essentially using using gitflow by Vincent Driessen (nvie).  It worked very well, but the needs of project have changed, so here are the new requirements:\n\n1.  A \"Beta\" environment that contains stable code for all features being considered for \"Production.\"\n2.  A \"Production\" environment.  Rock-solid, well-tested code only.  \n\nThe catch is that after a feature has been stomped on in Beta, it **may** go to Production, but only if Product Managers still think it is an important feature.  In other words, there is no guarantee that a feature in Beta will ever make it to Production.  It may be axed completely, in which case it would never get to Production and would be taken out of Beta.  Also, there is no guarantee that features that do make it to Production will go in in the order that they went in to Beta.  \n\nA few notes that may matter:\n\na) Six developers on team and growing.  Will be 9 by the summer.\nb) Codebase is 110K in-house lines.\nc) Typically, a feature is worked on by 1-3 developers at a time.  Total development work on a feature can be anywhere from two hours to two months.  The median is about two weeks.\nd) Currently, per week, about 15 bug reports come in for today's equivalent of the Beta branch.\n\nIdeally, using the new workflow, releases to Beta would be a few times per week.  Releases to Production would be once per month.  This is the same as our current release cycle.\n\nI have been on the whiteboard trying to think about a Git workflow that suits my needs, but my head is spinning, which is a signal to me that I need help from more seasoned vets.  Any and all help is appreciated.\n\n-Joseph"},{"id":"163354","messageId":"868vwh47ss.fsf@red.stonehenge.com","threadId":"26733","inReplyTo":"324BE2A8-5987-4324-AE27-D5CC01341710@appnexus.com","subject":"Re: Git workflow for beta/production","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2011-03-14T23:10:59Z","receivedAt":"2011-03-14T23:10:59Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Joseph\" == Joseph Huttner <jhuttner@appnexus.com> writes:\n\nJoseph> The catch is that after a feature has been stomped on in Beta,\nJoseph> it **may** go to Production, but only if Product Managers still\nJoseph> think it is an important feature.  In other words, there is no\nJoseph> guarantee that a feature in Beta will ever make it to\nJoseph> Production.  It may be axed completely, in which case it would\nJoseph> never get to Production and would be taken out of Beta.  Also,\nJoseph> there is no guarantee that features that do make it to\nJoseph> Production will go in in the order that they went in to Beta.\n\nSounds like you want the same sort of workflow that git itself uses,\nwith topic branches.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.posterous.com/ for Smalltalk discussion\n"},{"id":"163353","messageId":"7vlj0hb8lq.fsf@alter.siamese.dyndns.org","threadId":"26733","inReplyTo":"324BE2A8-5987-4324-AE27-D5CC01341710@appnexus.com","subject":"Re: Git workflow for beta/production","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-14T23:11:45Z","receivedAt":"2011-03-14T23:11:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joseph Huttner <jhuttner@appnexus.com> writes:\n\n> I am in search of a new Git workflow.  Previously, my team was\n> essentially using using gitflow by Vincent Driessen (nvie).  It worked\n> very well, but the needs of project have changed, so here are the new\n> requirements:\n>\n> 1.  A \"Beta\" environment that contains stable code for all features\n> being considered for \"Production.\"\n> 2.  A \"Production\" environment.  Rock-solid, well-tested code only.  \n>\n> The catch is that after a feature has been stomped on in Beta, it\n> **may** go to Production, but only if Product Managers still think it is\n> an important feature.  In other words, there is no guarantee that a\n> feature in Beta will ever make it to Production.  It may be axed\n> completely, in which case it would never get to Production and would be\n> taken out of Beta.  Also, there is no guarantee that features that do\n> make it to Production will go in in the order that they went in to Beta.\n\nIs it just me, or does the above sound exactly like how git itself is\nmanaged, when \"Beta\" and \"Production\" are read as \"next\" and \"master\"?\n\n> A few notes that may matter:\n>\n> a) Six developers on team and growing.  Will be 9 by the summer.\n\n120 active developers on team for the last 6 months, among which 35 people\nhave more than 5 commits.\n\n> b) Codebase is 110K in-house lines.\n\n157k lines counting only '*.[ch]' files.\n\n> c) Typically, a feature is worked on by 1-3 developers at a time.  Total\n> development work on a feature can be anywhere from two hours to two\n> months.  The median is about two weeks.\n\nQuite similar.\n\n> d) Currently, per week, about 15 bug reports come in for today's\n> equivalent of the Beta branch.\n\nGit being a volunteer project it is probably harder to compare; we have\nbusy weeks and quiet weeks.  For the past 6 months, I count 230 merges to\nthe 'mater' that merges fully cooked topics, so that is roughly 8-9 topics\na week.\n\n> Ideally, using the new workflow, releases to Beta would be a few times\n> per week.  Releases to Production would be once per month.  This is the\n> same as our current release cycle.\n\nI do merges to 'next' roughly once per day (sometimes twice a day,\nsometimes once every other day), and 'master' roughly twice a week.\n\nAll of the above makes me suspect that imitating what I do and other\npeople work with me might be one possible approach.\n"},{"id":"163384","messageId":"1300191033.18178.41.camel@drew-northup.unet.maine.edu","threadId":"26733","inReplyTo":"324BE2A8-5987-4324-AE27-D5CC01341710@appnexus.com","subject":"Re: Git workflow for beta/production","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-03-15T12:10:33Z","receivedAt":"2011-03-15T12:10:33Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Mon, 2011-03-14 at 15:27 -0700, Joseph Huttner wrote:\n> I am in search of a new Git workflow.  Previously, my team was\n> essentially using using gitflow by Vincent Driessen (nvie).  It worked\n> very well, but the needs of project have changed, so here are the new\n> requirements:\n> \n> 1.  A \"Beta\" environment that contains stable code for all features\n> being considered for \"Production.\"\n> 2.  A \"Production\" environment.  Rock-solid, well-tested code only.  \n> \n> The catch is that after a feature has been stomped on in Beta, it\n> **may** go to Production, but only if Product Managers still think it\n> is an important feature.  In other words, there is no guarantee that a\n> feature in Beta will ever make it to Production.  It may be axed\n> completely, in which case it would never get to Production and would\n> be taken out of Beta.  Also, there is no guarantee that features that\n> do make it to Production will go in in the order that they went in to\n> Beta.  \n\nHi Joseph,\nFirst off, don't discard the baby with the bathwater. If Nvie's workflow\nwas working for you don't discard it completely and outright--that's\njust asking for problems. Second, don't be afraid to be aggressive about\nrewinding your \"beta\" branch (as noted that's \"next\" around here at\ngit.git, but \"pu\" might be an even better model).\nIt sounds to me as if just one additional \"branch family\"--a \"customer\"\nbeta--could be added to Nvie's base structure to accomplish what you\nneed. The policy on this new track would be to expect it to be\nrewound/rebased/restructured frequently. From there whole features would\nbe picked out (per management decision) and put into the equivalent of\nthe \"[proposed] release\" branches and whole public releases pushed from\nthere to master (\"release\" would therefore also be rewound as\nneeded--hopefully not very often) for packaging. The major change in\ncode flow is that things no longer migrate back from \"release\" to\n\"development\" (bleeding-edge), \"beta\" (aka a \"customer beta\"--which is\nwhat your management team seems to be asking for), or anywhere other\nthan master--basically making \"release\" a clean-room version of beta\nwith no new code in it.\nI would not advise outright discarding of any \"hotfixes\" branch you\nhave, I would just make it merge to master only via \"beta\" and \"release\"\nexcept in cases of emergency. Let the management team decide what\nqualifies as that kind of emergency.\n\nWhy continue to have the \"release\" branch at all? Well, it sounds to me\nas if you are being asked to make absolutely certain that what makes it\nto master (and therefore what makes it to your packagers) is tested as a\nwhole unit. You can't do that cherry-picking directly from beta to\nmaster (customer production code). Having the \"clean-room\" post-beta\n\"rc\" branch gives you a safe place to do this--good for cases when\nsomebody insists on including \"feature y\" from the customer beta without\nalso including \"feature x\" forgetting that y depends on x to build or\nrun properly. This should have all been hashed out in beta--but that's\nharder to do when beta is considered to be a \"new feature customer demo\"\nbranch as well as \"beta\" branch. So, the moral of the story is roll\nstuff into a safe place after the \"feature demo\" beta for approval and\nunit testing before pushing to master and risking causing confusion in\nthe ranks of the packaging team. (It is never good when a customer hears\nthat a vendor didn't mean for them to be sent version n.xx of the\nproduction code but instead meant to send them n.xy.)\n\nGood luck!\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"}]}