Fix'n bugs...
Gosh, it's been a couple weeks since I last blogged, amazing how easy it is to neglect when busy but that's no excuse!
So what have I been doing in the past couple of weeks on Team Foundation System you ask. Well mostly bug fixing. We're getting close to shipping our Beta 2 so we've had a lot of bugs to fix and/or triage to move into our RTM (Release to manufacturer, internal term we use for our final release) bucket.
Maybe I'll talk a little bit about how that process works for our team. We have a lot of people working on finding problems with our current code, we have the QA team and PMs working on the latest bits and pretty much everyone on the project running our dogfood system. So as soon as they find a potential bug or something that isn't quite up to spec they will file a bug (in our dogfood system of course).
Our dogfood system is getting a bit old now, gosh I think we're still using the CTP bits we released in December, we have to use a stable drop and it's great to use what our customers are using as well so we can feel the pain as well and make sure to fix issues for the next drop.
All bugs are opened against our Beta 2 branch (in work item tracking this is the "iteration path" on our form) and they get assigned to a user called "active". Daily from 4-5pm we review(triage) all bugs that have come in by querying for all the beta2 bugs. For our teams' (work item tracking) bugs we usually have a representative from QA, PM, client dev and backend dev present to go over the list. The first thing we do is understand the bug and then decide if it needs to be fixed for beta 2 or can we "punt" it to RTM which is a bucket we put all issues we will fix after beta 2 is released. The bug is then assigned to the appropriate developer to fix. Only serious bugs are considered right now for beta 2 such as ones that could affect user data, crash the system, or prevent user adoption.
The triage team also goes over all the bugs previously assigned to beta 2 and gets status on each one. It is each developers highest priority to fix beta 2 bugs right now. The developer then needs to get a fix ready, have it code reviewed by QA and another developer and have it buddy tested. Once all that is done they need to enter all this information into the bug including a diff of the code. We then mark the bug status as "submit" so that the Burton triage team which meets daily can look it over to make a decision if the bug and fix will be accepted or not. It's a long process but we have to be diligant as we get closer to ship time. If the Burton triage team accepts it, a PM usually takes the bug to the Whidbey triage team to ask their approval to submit the fix and provide justification as to why it needs to be fixed. They also go over the code changes and try to understand the issue. We really need to keep the code base stable so we can ship it and so it gets harder and harder to get a fix in the closer we get to the ship date, which also means as developers we have less bugs to fix right now for beta 2 since only very serious issues are considered. If they accept this, we then have 24 hours to submit the bug to the beta 2 code branch and if we miss that window have to bring it back to triage to get approved again.
So for the past couple of weeks I've been working on various beta 2 bugs and when not working on those I've been going through my list of RTM bugs and working on those. As an example of some of the bugs I've been working on one comes to mind. I own the file attachments for work items and I recently noticed downloading files was taking a really really long time. We use HTTP Post and Get to upload and download file attachments to our server. I ran a test and noticed downloading a 22 meg file took 12 minutes. Wow that sucks!!!
So I took a look at how I originally coded it and narrowed it down to the chunk size I was sending the file back with. I was using 4k chunks which is OK for small files but not for big files. I upped it to 64k and the download went down to 35 seconds I then upped it to1 meg and the download took about 5 seconds. I also played with using HTTPResponse TransmitFile() method which will transmit the file at the kernel layer and handle the chunking for me and found it would download it in a matter of seconds. The TransmitFile seemed like the best way to go however we need some time to test it, so the question came up of what should we do for the beta 2 release vs the real release. So we decided the low cost fix for beta 2 was to up the chunk size to 64k (1 meg was faster but that means a meg of member being used in the web process space per download which wouldn't scale that well). It's a short fix with very low regression. But for our RTM branch we're going to use TransmitFile since we'll have a lot more time to test it out to make sure it scales and is stable.
I hope that gives a little glance at some of the things we're working on over here. I'll also talk this week about some new code changes we're making for RTM. Although my wife and I are expecting a new baby girl within the next week, so if I get the phone call I may not be around for a few days.
Hope you all have a great week.
Sam
This posting is provided "AS IS" with no warranties, and confers no rights.
