4 ms·

Continuous deployment makes releases non-events

28 points by ashmaurya 17y ago

mpstx 17y ago
I've adopted a strategy (on flexvite.com) where I test and push each change immediately, but periodically roll-up and announce a list of changes since the last roll-up. I'm still calling these roll-up summaries 'releases' on the web site since people are familiar with that concept. I've received some positive feedback about using this approach. People like the immediacy of how quickly their feedback is addressed, but they also like being able to thumb through a summary of "What's new" since they last looked. Here are some examples of those summary pages (they look just like release changelogs): 1. http://blog.flexvite.com/2009/12/17/flexvite-splat-release/ http://blog.flexvite.com/2009/12/17/flexvite-splat-release/ 2. http://blog.flexvite.com/2009/11/11/pow-10-new-flexvite-beta-improvements/ http://blog.flexvite.com/2009/11/11/pow-10-new-flexvite-beta... 3. http://blog.flexvite.com/2009/10/12/14-new-flexvite-beta-improvements/ http://blog.flexvite.com/2009/10/12/14-new-flexvite-beta-imp... The hardest thing for me is deciding where to draw the line and do an announcement of changes that have been released recently. I've considered announcing individual changes one-by-one as they happen on appropriate mediums (i.e.-twitter), but it seems like it would be a little spammy.
ashmaurya 17y ago
I think a blog is the perfect medium for a periodic roll-up announcing new and noteworthy items. This allows you to highlight specific themes that can appeal to both current and border-line users. I agree real-time tweets would be too spammy (unless you have a twitter account just for releases) but a community forum might be better for immediate announcements.
- DTrejo 17y ago
  Great article Ash, I really enjoyed it :)
btilly 17y ago
I have seen this work and work well on a large website that was simultaneously releasing in something like 20 different languages. However that company was not in the USA. And I see no way to square that development philosophy with Sarbanes-Oxley, so publicly traded companies in the USA cannot do it. But for an interesting example of a large well-known open source project with something like that development philosophy, check out http://clang.llvm.org/ http://clang.llvm.org/. The strategy scales better than you'd expect!
- thwarted 17y ago
  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.

28 points by ashmaurya 17y ago

mpstx 17y ago

I've adopted a strategy (on flexvite.com) where I test and push each change immediately, but periodically roll-up and announce a list of changes since the last roll-up. I'm still calling these roll-up summaries 'releases' on the web site since people are familiar with that concept. I've received some positive feedback about using this approach. People like the immediacy of how quickly their feedback is addressed, but they also like being able to thumb through a summary of "What's new" since they last looked. Here are some examples of those summary pages (they look just like release changelogs): 1. http://blog.flexvite.com/2009/12/17/flexvite-splat-release/ http://blog.flexvite.com/2009/12/17/flexvite-splat-release/ 2. http://blog.flexvite.com/2009/11/11/pow-10-new-flexvite-beta-improvements/ http://blog.flexvite.com/2009/11/11/pow-10-new-flexvite-beta... 3. http://blog.flexvite.com/2009/10/12/14-new-flexvite-beta-improvements/ http://blog.flexvite.com/2009/10/12/14-new-flexvite-beta-imp... The hardest thing for me is deciding where to draw the line and do an announcement of changes that have been released recently. I've considered announcing individual changes one-by-one as they happen on appropriate mediums (i.e.-twitter), but it seems like it would be a little spammy.

ashmaurya 17y ago

I think a blog is the perfect medium for a periodic roll-up announcing new and noteworthy items. This allows you to highlight specific themes that can appeal to both current and border-line users. I agree real-time tweets would be too spammy (unless you have a twitter account just for releases) but a community forum might be better for immediate announcements.

DTrejo 17y ago
Great article Ash, I really enjoyed it :)

btilly 17y ago

I have seen this work and work well on a large website that was simultaneously releasing in something like 20 different languages. However that company was not in the USA. And I see no way to square that development philosophy with Sarbanes-Oxley, so publicly traded companies in the USA cannot do it. But for an interesting example of a large well-known open source project with something like that development philosophy, check out http://clang.llvm.org/ http://clang.llvm.org/. The strategy scales better than you'd expect!

thwarted 17y ago
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.