Why are you still deploying overnight?(briancrescimanno.com)
briancrescimanno.com
Why are you still deploying overnight?
http://briancrescimanno.com/2011/09/29/why-are-you-still-deploying-overnight/
1 comments
I have to completely disagree with this author. Even if you're confident in your code, send your best people to work on it, are able to rollout a phased deployment and have the capability for quick rollback in overnight or off-peak deployment is preferable. If ever there was anything to happen unless people affected by it the better. Why put the strain of peak traffic and bandwidth up against a brand-new deployment?
You make a good point. So does the article.
What I was wondering while reading the article: when will it become common that there is no peak or off-peak time? There are some businesses there now, but at some point there will be no such thing for most businesses.
What I was wondering while reading the article: when will it become common that there is no peak or off-peak time? There are some businesses there now, but at some point there will be no such thing for most businesses.
That's a good point that I honestly didn't think to bring up in the article directly--thought I did mention that for businesses operating globally, the notion of "overnight" becomes meaningless.
I think the first commenter took the notion a bit far; I didn't mean to imply that we should be deploying during your absolute busiest hours. However, I think deploying overnight is a bad idea--and, moreover, I think it's dangerous to assume that simply "avoiding your customers" is a scalable, long-term solution for deployment.
I think the first commenter took the notion a bit far; I didn't mean to imply that we should be deploying during your absolute busiest hours. However, I think deploying overnight is a bad idea--and, moreover, I think it's dangerous to assume that simply "avoiding your customers" is a scalable, long-term solution for deployment.
you're right, "avoiding your customers" is not a scalable long-term solution for deployment. As businesses, big or small become more global this will become a bigger problem. As I'm sitting here reading this I see a potential for new business. We need to find some way to filter traffic. Think about two different versions of the website existing at the same address and in front of the website sits a fork (like a fork in the road) that splits incoming traffic into two groups. As traffic comes in a portion, say 20% is then the diverted to your brand-new deployment while the rest, 80% is directed to your older site. It's almost like having an semi-open beta in regards to the new deployment. It will be tested in real time under real circumstances. Then as bugs get ironed out you can increase the ratio from 80 – 20 gradually until all traffic is now being fed into the brand-new live site.
so who wants to co-found this with me? we might be able to make it in time for the next round of Y Combinator!
by the way I didn't think you were saying that you should deploy during your busiest time, I just met all things being equal, the should definitely look for "off-peak" times to rollout new deployments. But we both seem to agree that the long-term solution. Globalization is going to make off-peak times a thing of the past. Hence see my solution above, we can get ahead of it and make some money.
by the way I didn't think you were saying that you should deploy during your busiest time, I just met all things being equal, the should definitely look for "off-peak" times to rollout new deployments. But we both seem to agree that the long-term solution. Globalization is going to make off-peak times a thing of the past. Hence see my solution above, we can get ahead of it and make some money.
Not sure there's a ton of money to be made; solutions like what you're describing already exist and are in use at mature development shops that understand that they don't have to be afraid to roll out new code at 9:30 am.