October 22, 2008 at 9:08 am
drnetwork (10/22/2008)
... if I tried to do that with my product (a higher education ERP), it would be a little different. In my case real money is changing hands and needs to be accounted for at a number of levels (GL, AP, AR, Payroll, Personnel/Benefits, Budgeting, Requisitioning/Purchasing, Registration/Tuition, Development, to name a few). And real data that affects real people lives and has real privacy information - your college transcript, for example - is maintained without the danger of corruption, compromise, or loss. We generally roll out 2-3 main releases a year that are fully QA'ed and beta tested on five different independent signed-off levels of testing and maybe 4-6 patches that have three different independent levels of testing.
Absolutely! The scope (for lack of a better word) of the changes definitely impacts how quickly you can thoroughly test and deploy. If someone were rolling out changes this quickly on an application that makes changes to databases like above, I think I'd be a little nervous!
Also, we don't even know how they define "changes". As someone else said, the numbers are really high... what if some of these changes are simply content?
October 22, 2008 at 10:18 am
roger.plowman (10/22/2008)
If you deploy 36 times in one week it means (assuming your coders are coding and testers are testing 24/7) you're deploying every 4.6 *hours*.Even with scripting languages that's outrageous.
Assuming an 8 hour 5 day week you're talking about deploying once per hour.
Sounds like BS to me...
Let's assume Flickr has 24/7 coding/testing. How in the world can you find the code to change, change it, and then test it in 4 and a half hours? Not to mention actually doing the deployment itself?
Automated tests are all well and good, but at such a pace it would mean you're depending almost entirely on them.
No wonder the web is so screwed up.
Now, if you told me they had a couple of deployments, with a grand total of 36 changes, that's hardly noteworthy, especially for a large coding/testing team. But 36 deployments a week? Very, very hard to believe.
That would assume that the change control is in fact single-threaded (which isn't necessarily the case). I didn't actually see mentioned that the 36 deployments happened to a single product/project either, so the numbers might be getting "cooked" a little. It's not been at all unusual for me to find that a single interface is in fact a whole host of free standing pieces (which don't interact with each other), which just happen to serve up in the same web
"space".
As to automated testing - it's one of those things you cannot do half-way, or it's worse than not having it at all. If you can't get a comprehensive test, showing you that you're not breaking existing code with the new changes, then it would be better (from my experience) not to do it at all, and go back to manual testing. Of course - if you DO have a good handle on your code base, and you DO have tests covering all of the requirements, why wouldn't you rely heavily on automated testing?
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
October 22, 2008 at 11:06 am
I'll second what Matt said. With a proper suite of trusted, automated tests, this is do-able... especially if there is proper separation of functionality instead of a monolithic approach to everything. We had weeks like that in startup-land, but we didn't have 100% automated testing and it wouldn't have been a long-term sustainable pace for us.
October 22, 2008 at 12:23 pm
It's doable, and depending on how large the site is, it's possible that you could deploy this hour to the front page, next to the account management, next to something else, all work being done in parallel.
The team mentioned is 20. Not sure if that's 20 developers + more QA or if it's 20 total, but you could deploy say 8-9 times a day, 4-5 days a week and be fine. I'd hope you have something like 8 or more separate areas of the site so things could work together, but it's entirely possible that you might upgrade a component in one area, say the upload component, let that stew and then deploy a change to another area tomorrow to use that component as well. Kind of rolling some things through the site.
Should this be the pace forever? Not sure. you'd think it would mature as things stabilize.
Is it bad for users? Think about this. There is some large percentage of features in Word or Excel that no one ever uses. There are things here on the site that we rarely see traffic in. Changing the site, doesn't mean radical UI overhauls, it might mean that we yank a word, reorder things, some small change that some people notice and some don't. As long as we don't break things, does it matter if some people notice a new feature and try to learn it? Especially if then next 30 changes next week don't get noticed by that person, but by someone else?
If you start to realize that not every change really impacts much of your audience (some do, but most don't), then you realize that even though you've spent 10 hours thinking about it and developing it, most people might never notice it or use it. Or they might find it a year from now.
Agile development doesn't mean bad design up front. It means doing something, and then reacting to it. Do more of what works, less of what doesn't, as Jason Fried would say.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply