[awinder]

I worked for a company that had gone from selling on premise software to cloud, and going from build to production release took a while. Realistically you could expect 1-2 days if everything went well. This was definitely not problem #1 at the company but I really wanted to push to see how much time we could shave off. I got some like-minded teammates to put time into a new release pipeline process, and we built some nice integrations where you could control the release process & see results from inside of slack.

So there were 2 kinds of big categories of things that happened. One was that we really slashed the amount of time from first master branch build to deployment. If things went well we could release to production in under an hour. This radically changed everything about our process. We started building smaller stuff because we could try things out in production very quickly. Code review times dropped a lot because we had smaller units of code. Planning meetings went faster because we were talking about smaller things so discussions didn’t go sideways. The team seemed to really like it.

Second class of thing that happened was that people from other teams would drop by our slack channel and see us rolling out code by talking/clicking to a bot, and they’d want to know more. And then we’d show the speed improvements and how it integrated into the rest of the prod architecture so that you could make the migration to using it too. So it kinda organically became the defacto release architecture at the company over time.

I’m a little bummed out now because it was super fun to see this all go down, it was almost accidentally the most far-reaching change I’ve instigated at work and the impact was great.

[jwcrux]

You’d love _The Unicorn Project_ if you haven’t read it. I highly recommend it, and it’s a story around roughly the same journey.

https://www.amazon.com/Unicorn-Project-Developers-Disruption...

[kqr]

And/or anything related to the state of devops report. Nicole Forsgren et al. are doing amazing work in observational science around this.

The gist of it is that reducing your time-to-production is one of the best investments you can make. It changes everything about how you build things.

[baroomba]

I think the harm done by long, painful, dangerous releases and complex onboarding or different experiences and expectations for how to effectively test and get a good dev feedback loop going in various components of a system (usually these things occur together, because the same things that cause the latter also cause the painful, slow, dangerous releases) is badly under-accounted for. It murders agility yet companies wander their way into it in the name of agility then don't ever fix it because the fix is slow and dangerous since everything is slow and dangerous.

[EDIT] to be clear, quick painful dangerous releases are no better, and (pretty much necessarily) come with the same pain in onboarding, jumping between repos/projects, undocumented "oh sometimes you have to re-install that to get it going" works-on-my-machine bullshit, getting a good feedback loop going, et c.

[atmosx]

Where you able to see error logs from slack or you used a link? Granted that usually traces are multiline, I expect them to be hard to read on slack but the again nothing beats lack of context switch.

[awinder]

We linked out to the logs, I kinda wanted to figure something else out for slack to embed them but it ended up not working out. But you’re right it’s kinda appealing