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.
@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.