info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Changing the development / QA period to two weeks
14 views
Skip to first unread message
Lloyd Hilaiel
Feb 9, 2012, 2:10:06 PM2/9/12
to dev-id...@lists.mozilla.org
Previously, BrowserID has been built using one week "trains". This meant there would be a week of development, after which a "train" would be split off and tested by QA, after which it would either roll into production or be derailed if severe issues were found. While one train is in testing, development progresses. These periods have been awesome to get browserid off the ground and stay nimble, but now have begun to fall apart.
Over the last months we've repeatedly found that we've needed to double testing time when large features land, as we've raised the bar for the level of quality we require going out the door given more and more people are depending on browserid for their site to function.
The final straw, is we are now localizing browserid into about 40 different locales. This work is done by an amazing group of community folks, and they all actually volunteer their time to help browserid speak your language. The shortest reasonable cycle to allow contributors to step in and update translations for a rolling train is two weeks (giving folks a couple weekends that they can come in and translate).
We considered several different changes to the development process, and settled on the simplest one to understand:
Our train period now runs for two weeks, and everything else is unchanged.
Starting wednesday Feb 15th we aim to roll our present train into production (with localization support!) and switch over to longer cycles. We'll get better about announcing the movement of trains and if you are:
* A localizer: there's a two week window to update translations
* A tester: there's a two week period to test the snot out of the train
* A user of browserid: two week window where you yourself can jump in and file issues against our beta code
A final note about the cadence of development, we'll now informally break our dev into three cycles : the handful of days after a train goes to testing are focused on supporting QA and quickly diagnosing potential blocking issues, and creating fixes if appropriate. The week after that is about new development or addressing issues. The couple days before a train rolls is an informal feature freeze where we focus on dev team driven vetting of the train about to roll into testing to minimize the occurrences of high cost, high risk fixes after a train has rolled (the stuff that derailments are made of).
curious for your thoughts,
lloyd
Over the last months we've repeatedly found that we've needed to double testing time when large features land, as we've raised the bar for the level of quality we require going out the door given more and more people are depending on browserid for their site to function.
The final straw, is we are now localizing browserid into about 40 different locales. This work is done by an amazing group of community folks, and they all actually volunteer their time to help browserid speak your language. The shortest reasonable cycle to allow contributors to step in and update translations for a rolling train is two weeks (giving folks a couple weekends that they can come in and translate).
We considered several different changes to the development process, and settled on the simplest one to understand:
Our train period now runs for two weeks, and everything else is unchanged.
Starting wednesday Feb 15th we aim to roll our present train into production (with localization support!) and switch over to longer cycles. We'll get better about announcing the movement of trains and if you are:
* A localizer: there's a two week window to update translations
* A tester: there's a two week period to test the snot out of the train
* A user of browserid: two week window where you yourself can jump in and file issues against our beta code
A final note about the cadence of development, we'll now informally break our dev into three cycles : the handful of days after a train goes to testing are focused on supporting QA and quickly diagnosing potential blocking issues, and creating fixes if appropriate. The week after that is about new development or addressing issues. The couple days before a train rolls is an informal feature freeze where we focus on dev team driven vetting of the train about to roll into testing to minimize the occurrences of high cost, high risk fixes after a train has rolled (the stuff that derailments are made of).
curious for your thoughts,
lloyd
Daniel Mills
Feb 9, 2012, 2:50:33 PM2/9/12
to Lloyd Hilaiel, dev-id...@lists.mozilla.org
Are the trains overlapping? IOW, do we plan to release every week, or every two?
One concern (which might not be a valid one) if we do releases every two weeks is that it will be harder not to lump multiple features together--eg there would have been more pressure to release primaries and l10n on the same release. Well, maybe that's an extreme example, but you know what I mean.
Dan
> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
One concern (which might not be a valid one) if we do releases every two weeks is that it will be harder not to lump multiple features together--eg there would have been more pressure to release primaries and l10n on the same release. Well, maybe that's an extreme example, but you know what I mean.
Dan
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
Ben Adida
Feb 9, 2012, 3:01:50 PM2/9/12
to dev-id...@lists.mozilla.org
On 2/9/12 11:50 AM, Daniel Mills wrote:
> Are the trains overlapping? IOW, do we plan to release every week, or every two?
No, we opted against that. Release every two weeks.
> Are the trains overlapping? IOW, do we plan to release every week, or every two?
> it will be harder not to lump multiple features together
in *now*" trap. But I think the 2-week cycle will be healthier overall.
-Ben
Tony Chung
Feb 9, 2012, 3:20:22 PM2/9/12
to Ben Adida, dev-id...@lists.mozilla.org
On Feb 9, 2012, at 12:01 PM, Ben Adida wrote:
>> it will be harder not to lump multiple features together
>
> You're right that we'll have to not fall prey to the "get this feature in *now*" trap. But I think the 2-week cycle will be healthier overall.
>
> -Ben
Tony
Dan Mills
Feb 9, 2012, 11:16:02 PM2/9/12
to Ben Adida, dev-id...@lists.mozilla.org
On Thursday, February 9, 2012 at 12:01 PM, Ben Adida wrote:
> On 2/9/12 11:50 AM, Daniel Mills wrote:
> > Are the trains overlapping? IOW, do we plan to release every week, or every two?
>
>
> No, we opted against that. Release every two weeks.
Okay. Sounds good, so long as we're not just slowing down dev :-)
> On 2/9/12 11:50 AM, Daniel Mills wrote:
> > Are the trains overlapping? IOW, do we plan to release every week, or every two?
>
>
> No, we opted against that. Release every two weeks.
Dan
Lloyd Hilaiel
Feb 10, 2012, 10:13:06 AM2/10/12
to Dan Mills, Ben Adida, dev-id...@lists.mozilla.org
On Feb 9, 2012, at 9:16 PM, Dan Mills wrote:
> Okay. Sounds good, so long as we're not just slowing down dev :-)
I initially was scared that this is what we'd be doing.
> Okay. Sounds good, so long as we're not just slowing down dev :-)
Stepping back now with all things considered, I'm hopeful that a 2 week period will actually improve throughput and decrease risk. It'd be useful to revisit this after we've got two trains out on the new period to check in.
lloyd
Dan Mills
Feb 10, 2012, 12:45:41 PM2/10/12
to Lloyd Hilaiel, Ben Adida, dev-id...@lists.mozilla.org
Dan
0 new messages