4 ms·

Can you explain the challenge Sarbanes-Oxley gives those publicly traded companies who want to do continuous deployment?

btilly 17y ago
Publicly traded companies need to have carefully set up internal controls and audit trails on anything that can materially impact the company's financial position. If you are a web-based company, this would include the process of releasing to the website. I do not see how to reconcile these controls and audits with the ability for developers to release main to production whenever they please. There may be a way to do it, but I don't see how.
- thwarted 17y ago
  You can have continual deployment without it being a developer free for all. Features get released as they are ready, there are enough developers that there's something that can go out on a regular basis. Which features those are and how they are implemented and the schedule is still determined by those driving the direction of the company.
  - btilly 17y ago
    The concrete example I was thinking of was, in your terms, "a developer free for all". As in there were checks and balances, but fundamentally any developer could decide to release to production at any time for any reason. And typically this happened several times per day. Incidentally my opinion is that rapid iterations in production and branching your code base are opposed decisions. Why? Because the whole point of rapid iterations to production is to make sure that your code and production are very, very close together. But the whole point of branching is to make it OK for your code and code in other places (including production) to be different. This shows up in practice in the complexity and potential problems that you encounter while integrating branches. This pushes you towards a more lengthy verification/QA cycle, which pushes you away from rapid iterations to production.

btilly 17y ago

Publicly traded companies need to have carefully set up internal controls and audit trails on anything that can materially impact the company's financial position. If you are a web-based company, this would include the process of releasing to the website. I do not see how to reconcile these controls and audits with the ability for developers to release main to production whenever they please. There may be a way to do it, but I don't see how.

thwarted 17y ago
You can have continual deployment without it being a developer free for all. Features get released as they are ready, there are enough developers that there's something that can go out on a regular basis. Which features those are and how they are implemented and the schedule is still determined by those driving the direction of the company.
- btilly 17y ago
  The concrete example I was thinking of was, in your terms, "a developer free for all". As in there were checks and balances, but fundamentally any developer could decide to release to production at any time for any reason. And typically this happened several times per day. Incidentally my opinion is that rapid iterations in production and branching your code base are opposed decisions. Why? Because the whole point of rapid iterations to production is to make sure that your code and production are very, very close together. But the whole point of branching is to make it OK for your code and code in other places (including production) to be different. This shows up in practice in the complexity and potential problems that you encounter while integrating branches. This pushes you towards a more lengthy verification/QA cycle, which pushes you away from rapid iterations to production.