3 ms·

Rapid release has nothing to do with shifting UI. You can have constantly shifting UI even with weekly release.

vladvasiliu 4y ago
I presume GP would call a weekly release "rapid", too. Given the tone of the message, I expect "non rapid" to mean with a much longer time frame, and, most importantly, the release must be controllable by the user.
- jen20 4y ago
  > most importantly, the release must be controllable by the user. This is pining for a world which no longer exists, because security patches must be applied to anything that matters immediately.
  - lazide 4y ago
    There are things called ‘branches’ you know.
  - diffeomorphism 4y ago
    That is completely orthogonal and the whole selling point of things like Windows LTSC or Red Hat: Stable foundations with regular security updates but no surprises.
  - Silhouette 4y ago
    It is possible to separate security updates and other critical bug fixes from functional/UI changes. At least it is if you're any good at software development at all. The world would be a better place for users if more software developers still did that. Of course you do need a strategy for maintaining multiple versions of something in that case instead of just forcing the latest version of everything you do on users whether they want it or not. With the lock-in effects of the always-connected web applications of today we all know which option makes more money. I take some comfort in knowing that eventually most of the developers that force unwanted changes on their users will probably see their market share erode and lose their dominant positions. It's just unfortunate that we have so many quasi-monopolies in both essential and niche software products that it's going to take a long time for that to happen.
  - pdntspa 4y ago
    Why should something like a drawing app, or a music app, or anything else that doesn't need to be online, need this kind of patch schedule? This world does in fact still exist, this is how most OSS works!
- JohnFen 4y ago
  Yes, weekly is certainly rapid.
theptip 4y ago
Yes, was going to post the same reply. Iterative UI, A/B testing, webapp-driven (vs. installed versioned apps) are completely orthogonal to the OP discussion of Continuous Deployment / rapid deployment. CD is a deploy strategy saying the aspiration is to do one deploy per commit, rather than batching commits and deploying once per N weeks or whatever. It has approximately zero to do with UX and product design/iteration approaches.
- wizofaus 4y ago
  One deploy per commit for a product with large team sounds insane - we'd easily have 50 commits a day for some hosted components. Even deploying this often to the non-prod environments is problematic (it takes a fair bit longer than 1/50th a day for a start!), but doing that to your customer-facing production sites sounds bonkers - what class of problems is there that that's the best way to prevent them?
  - theptip 4y ago
    Yes it's aspirational, and of course you have to do batching when the rate of commits gets too high. Many companies don't actually end up at the end of the spectrum with full continuous delivery; most of the value is captured by building what's needed _to be able to_ if you chose to, and doing say daily or hourly automated deploys. If you're not familiar with the general arguments for why CD might be desirable, a good place to start would be the books Continuous Delivery [https://smile.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley-ebook/dp/B003YMNVC0/ https://smile.amazon.com/Continuous-Delivery-Deployment-Auto...] or Accelerate [https://smile.amazon.com/Accelerate-Software-Performing-Technology-Organizations-ebook/dp/B07B9F83WM/ https://smile.amazon.com/Accelerate-Software-Performing-Tech...]. The TLDR would be that most deploy problems in practice turn out to be because the process is manual, infrequently-used, and/or unreliable, and by practicing "if it hurts, do it more often" you are forced to iron out those kinks. For example you can't deploy automatically without a good acceptance/smoke test suite, and without solid DB migration testing/linting/practices, to name just two of many. You could just build all these things without trying to do CD, but in practice it seems that it's quite hard for organizations to prioritize this work in isolation, and the goal of CD seems to provide a fairly clear map to a much higher-quality deploy process. The practice of deploying more frequently to flush out issues, is also quite unintuitive as you note. Here's a (probably out-of-date) article on how FB did deploys in 2017: https://www.infoq.com/news/2017/09/facebook-release-scale/ https://www.infoq.com/news/2017/09/facebook-release-scale/ -- batched commits and staged canary rollouts automatically cut and released every few hours.
bluGill 4y ago
I've worked with software that has to work. Our customers put it in a lab where they beat on it in simulation for 3 more, months - any bugs and they stuck with the old version. (which is one reason land lines were so reliable in the 1990s) We did a code freeze 6 months before release in hopes of catching everything. Most software nobody cares if it works or even is possible for untrained humans to use, and it shows.
- morelisp 4y ago
  The glut of isolated B2C SaaS products/developers has absolutely destroyed any communal valuation of “known issues.” True in-house heads still remember.

I presume GP would call a weekly release "rapid", too. Given the tone of the message, I expect "non rapid" to mean with a much longer time frame, and, most importantly, the release must be controllable by the user.

jen20 4y ago
> most importantly, the release must be controllable by the user. This is pining for a world which no longer exists, because security patches must be applied to anything that matters immediately.
- lazide 4y ago
  There are things called ‘branches’ you know.
- diffeomorphism 4y ago
  That is completely orthogonal and the whole selling point of things like Windows LTSC or Red Hat: Stable foundations with regular security updates but no surprises.
- Silhouette 4y ago
  It is possible to separate security updates and other critical bug fixes from functional/UI changes. At least it is if you're any good at software development at all. The world would be a better place for users if more software developers still did that. Of course you do need a strategy for maintaining multiple versions of something in that case instead of just forcing the latest version of everything you do on users whether they want it or not. With the lock-in effects of the always-connected web applications of today we all know which option makes more money. I take some comfort in knowing that eventually most of the developers that force unwanted changes on their users will probably see their market share erode and lose their dominant positions. It's just unfortunate that we have so many quasi-monopolies in both essential and niche software products that it's going to take a long time for that to happen.
- pdntspa 4y ago
  Why should something like a drawing app, or a music app, or anything else that doesn't need to be online, need this kind of patch schedule? This world does in fact still exist, this is how most OSS works!
JohnFen 4y ago
Yes, weekly is certainly rapid.

theptip 4y ago

Yes, was going to post the same reply. Iterative UI, A/B testing, webapp-driven (vs. installed versioned apps) are completely orthogonal to the OP discussion of Continuous Deployment / rapid deployment. CD is a deploy strategy saying the aspiration is to do one deploy per commit, rather than batching commits and deploying once per N weeks or whatever. It has approximately zero to do with UX and product design/iteration approaches.

wizofaus 4y ago
One deploy per commit for a product with large team sounds insane - we'd easily have 50 commits a day for some hosted components. Even deploying this often to the non-prod environments is problematic (it takes a fair bit longer than 1/50th a day for a start!), but doing that to your customer-facing production sites sounds bonkers - what class of problems is there that that's the best way to prevent them?
- theptip 4y ago
  Yes it's aspirational, and of course you have to do batching when the rate of commits gets too high. Many companies don't actually end up at the end of the spectrum with full continuous delivery; most of the value is captured by building what's needed _to be able to_ if you chose to, and doing say daily or hourly automated deploys. If you're not familiar with the general arguments for why CD might be desirable, a good place to start would be the books Continuous Delivery [https://smile.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley-ebook/dp/B003YMNVC0/ https://smile.amazon.com/Continuous-Delivery-Deployment-Auto...] or Accelerate [https://smile.amazon.com/Accelerate-Software-Performing-Technology-Organizations-ebook/dp/B07B9F83WM/ https://smile.amazon.com/Accelerate-Software-Performing-Tech...]. The TLDR would be that most deploy problems in practice turn out to be because the process is manual, infrequently-used, and/or unreliable, and by practicing "if it hurts, do it more often" you are forced to iron out those kinks. For example you can't deploy automatically without a good acceptance/smoke test suite, and without solid DB migration testing/linting/practices, to name just two of many. You could just build all these things without trying to do CD, but in practice it seems that it's quite hard for organizations to prioritize this work in isolation, and the goal of CD seems to provide a fairly clear map to a much higher-quality deploy process. The practice of deploying more frequently to flush out issues, is also quite unintuitive as you note. Here's a (probably out-of-date) article on how FB did deploys in 2017: https://www.infoq.com/news/2017/09/facebook-release-scale/ https://www.infoq.com/news/2017/09/facebook-release-scale/ -- batched commits and staged canary rollouts automatically cut and released every few hours.

bluGill 4y ago

I've worked with software that has to work. Our customers put it in a lab where they beat on it in simulation for 3 more, months - any bugs and they stuck with the old version. (which is one reason land lines were so reliable in the 1990s) We did a code freeze 6 months before release in hopes of catching everything. Most software nobody cares if it works or even is possible for untrained humans to use, and it shows.

morelisp 4y ago
The glut of isolated B2C SaaS products/developers has absolutely destroyed any communal valuation of “known issues.” True in-house heads still remember.