3 ms·
It has to do with how quickly you can iterate on your production software and what the distance is (in terms of time) between a developer committing a change an
by bitops 15y ago
It has to do with how quickly you can iterate on your production software and what the distance is (in terms of time) between a developer committing a change and that change making it out in front of an end-user.
In traditional enterprise software (e.g. insurance) the deployment cycles are long because the organization are large, heavily layered, and extremely resistant to change. There are many reasons for this, some sensible and some not. (And then some that are legislated - they fall into both categories).
For a startup that is trying to build a service, or a mid-sized corporation, particularly in the ecommerce space, the faster you can change a deployed solution, the better off you are.
Say you're running a large ecommerce website and a bug is discovered on the user account page. It's a "P1 issue" that needs immediate attention, i.e. as long as the bug exists, revenue is impacted.
In a situation like this, you want to be able to identify a fix, commit it, and ship it to production ASAP. This becomes an issue in traditional organizations where the "developers" are different from "the network people" who themselves are subdivided into database/network/sysadmin/etc. These groups are change-averse and tend to gate releases into maintenance windows. Which makes sense, but can hinder rapid deployment.
If you don't have a traditional Ops team, there's no stakeholder who feels you're impinging on their fiefdom when you wantonly hit the deploy button. (Though I don't mean to imply that you shouldn't have discipline around releases).
The question you're asking is very relevant for teams making the transition to processes like Agile and infrastructures like Cloud. Because these things are disruptive, they lead to change and break-down of traditional org structures. A dedicated QA department always seems to be one of the first things targeted. (Though I don't necessarily think that's a good idea).
- aphexairlines 15y agoI think you will find that even in large organizations with dedicated teams owning server ops, if a problem is impacting customers in the middle of the day, there will be a way to get the deployment window open quickly. Doing away with maintenance windows altogether sounds great from our point of view as developers, but it shouldn't come at the expense of customers suffering horrible latency during peak hours because the servers are at reduced capacity while a significant percentage of them are busy with deployments. I understand the benefits of rapid iteration through continuous deployment (and intensive automated testing), but cloud platforms like Heroku and Beanstalk don't really help here. Cloud deployment and the ability for developers to push a button and have their changes show up in production quickly also doesn't mean you don't need QA anymore. That's a separate decision. I understand that making deployment a simpler process through hosted server farms is great in that it takes off a lot of pressure from your ops team, but that doesn't change the development process.