4 ms·

I find the article somewhat ridiculous in that it takes the tone that everyone thinks the idea in question are good. > They aren’t convinced that some of the s

I find the article somewhat ridiculous in that it takes the tone that everyone thinks the idea in question are good. > They aren’t convinced that some of the scarier ideas (like deploying multiple times per day) will help after all For some cases, rapid deployment might make sense (purely front end stuff). For a lot of cases, I'm firmly of the opinion that it does _not_ make sense. I've never worked on a project that deployed that often, and I don't feel the need to. I have depended on services that deployed that often and "oh, sorry we broke that, we'll fix it later; you'll just have to live with permanently broken data" gets my knickers in a twist every time. > I don’t buy into all the ideas behind agile, particularly some of the Scrum-specific ceremonies. That's because a lot of the Scrum people present it as "the" Agile. And a lot of the non-Scrum people are fairly convince that Scrum is awful. To which the Scrum people present "no true Scotsman" arguments. I'm all for the underlying "listen to your customer, listen often, and change plans as often as necessary to make them happy" ideas of Agile. But every "methodology and process" for it I've seen completely loses that idea. It's infuriating.

0x457 4y ago
I think your issue isn't rapid release cycle, but lack of proper testing.
- RHSeeger 4y ago
  Yes, but testing takes time. Automated testing is a wonderful thing, but it only catches those things that the testers have already though of AND have had the time to write automated tests for. Some things are notoriously difficult to automate testings of. And there are always things that don't get considered during the writing of tests; especially those things that only appear when multiple systems are interacting together. Taking the time to deploy code to a staging server, where QA can check it, and other systems can interact with it, can prove to be very beneficial. And runs contrary to having every push (or every push that passes the automated testing suite) automatically go to production. I'm a big fan of something like a 2 week release cycle, plus the ability to release quickly when needed (generally same day, but only when necessary). I'm a big fan of automated tests (both unit and integration, both dev and QA written), plus a QA person/team to bang on things in a way developers don't think of, plus a staging environment where all the (staging versions of the) system interact with each other. I'm not a fan of pushing things to production willy nilly, with a high risk of breaking things "because you can push again with a fix in an hour".

0x457 4y ago

I think your issue isn't rapid release cycle, but lack of proper testing.

RHSeeger 4y ago
Yes, but testing takes time. Automated testing is a wonderful thing, but it only catches those things that the testers have already though of AND have had the time to write automated tests for. Some things are notoriously difficult to automate testings of. And there are always things that don't get considered during the writing of tests; especially those things that only appear when multiple systems are interacting together. Taking the time to deploy code to a staging server, where QA can check it, and other systems can interact with it, can prove to be very beneficial. And runs contrary to having every push (or every push that passes the automated testing suite) automatically go to production. I'm a big fan of something like a 2 week release cycle, plus the ability to release quickly when needed (generally same day, but only when necessary). I'm a big fan of automated tests (both unit and integration, both dev and QA written), plus a QA person/team to bang on things in a way developers don't think of, plus a staging environment where all the (staging versions of the) system interact with each other. I'm not a fan of pushing things to production willy nilly, with a high risk of breaking things "because you can push again with a fix in an hour".