Doot-doot-doo... commitin' code directly to master 'cause everyone else on my team's out today....
BIAS THIS FOR ACTION, DEVVERS! :middle_finger_clw_b2:
(( Under ninety-nine percent of circumstances, this is a terrible move, but there's nobody around who can tell me if my code's good and I can only really test it if it's in staging. I've validated my rollback plan and prod is disconnected in my pipeline. I may take a cavalier attitude at times but I'm still a professional. ))
@literorrery Your staging environment runs on the master branch?
...D:
@mawr We have a full CI/CD setup. Everything runs on the master branch but is gated for release based on tags. It's so we can push as much crap as we like to side branches but only master-merges get auto-promoted from GitHub to our staging environment. This app doesn't have a full dev environment because of the nature of the project.
@literorrery @mawr also this is the “gold standard” of CI in a lot of places. The idea being that master -> automated tests -> deployment, with automated rollback if any of those stages fail.
It, uh, helps to have every merge CRed first.
@mawr @literorrery (it also makes sense to have a preflight branch that does all that and does a partial deployment, then merges to master only when the preflight all works out, but that is a lot more complicated to set up and isn’t always necessary depending on the momentum and impact of a service)
@fluffy @mawr And to be sure, under normal circumstances, I'm a huge stickler for CRs; I believe they catch more bugs than tests ever can. That I did this is kind of a process breakdown, but I have a team of three people of whom two were out at the time, a bugfix pending a blocking change in a package, and nobody to approve the package. So, I took the risk and noted that I was doing so in my PR citing the urgency of the bugfix.
It's still not good, but it was least pessimal.
@literorrery @mawr oh definitely! Tests can only find the issues you think to test for. Even 100% coverage isn’t necessarily testing incorrect assumptions and it certainly doesn’t find outlier issues in cross-function interactions.
Client team at my last place required 100% coverage which mostly just ended up testing the mocks about a billion times.
@literorrery I just imagined you doing that and comically everything around you just immediately catches fire and alarms blare
@Oneironott That would validate that my monitors are working! =n.n=
@literorrery suuuure you don't have any coyote in you :P
@Oneironott It's not _coyote_, but there is trickster. =>.>=
@literorrery ahaa :P Everyone needs a little trickster, I think n.n
And what do you know, it did go awry. Not terrible, just committed to the wrong repo. Ha ha. Time to validate that rollback plan....