You also reduce a shit ton of base-line anxiety around releases, giving the entire team an improved quality of life.
if you're on a 5-7 person eng team and have not automated the shit between merging your code and going live on prod, i'll bet each one of you wastes nearly a full day per week waiting on/tending to deploys. if you fix this, you've added a whole person of focus time to your team.
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
It also makes the onboarding of new team member way better!
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Ashamed to admit this is me. We've done some work but def haven't "automated the shit" out of it. With a small team it's so easy to rationalize putting these tasks at the bottom of the list. Thanks for the kick in the butt!
-
Economic arguments usually work here. Using average salary of team or regular participants, if you spend 10-20 minutes every day or whatever, you can quickly find the break even point, and use that to justify shaving bits off. This is a tight loop, everything helps.
End of conversation
New conversation -
-
-
You're assuming we deploy often? There's no need to automate something that you don't do :)
-
Automate for safty reasons, perhaps?
- Show replies
New conversation -
-
-
It is wonderful. There are so many fantastic software practices that I wish had equivalents elsewhere. Hardware has DRC and ECOs instead of unit tests and PRs, but I'd love it if I could build a set of automated tests before ordering a board like software has for deploys.
-
Gotta try this now. Hardware CI here I come!https://resources.altium.com/p/continuous-integration-implementation-using-altium-designer …
End of conversation
New conversation -
-
-
Also, you're de-risking ALL your future deploys, especially if you can add solid testing as part of this process from the beginning.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Sadly a lot of teams I've seen encourage dev ownership to stop at "works on my machine" thus all sorts of manual checks or gates or scripts pop up that are required to shift further. So a prerequisite would be to tear down the wall between ops and dev first.
-
Agree with this, and encourage appropriate ownership of the process/tools, so fewer people feel 'dumped on' by smart ass devs making their life complicated! Ops are a 1st class internal customer..
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.