3 ms·
We all do it for urgent fixes, the thing is to try to make it less holy to avoid "we cant fix this crushing bug before next release window" stupidity, but still
by secondaryacct 5y ago
We all do it for urgent fixes, the thing is to try to make it less holy to avoid "we cant fix this crushing bug before next release window" stupidity, but still holy to avoid "Ill fix it now in prod and forget abt that fix that Ill overwrite next release window" :D
- edgyquant 5y agoI work at a small startup right now but our motto is if it’s a 1 line fix we can just commit to master and deploy to prod. Anything that requires adding new logic or anything we run by the another engineer just to have another set of eyes look at it.
- secondaryacct 5y agoI work in a regulated bank and yday night I had to have an auditor look at us deploying a new version on one user, trigger one order, revert back. He ll then spend the next 3 days studying the changes (that we didnt test in front of him) to tell us if yes or not we can deploy. And god forbid we find a bug in prod, to rollback I suspect we ll need to retrigger an audit :D Next time you ask loudly your representatives to regulate banks even more, think of us poor assholes spending our time filling mindless paperwork :D
- names_are_hard 5y agoWe don't all do it for urgent fixes... where I work, I couldn't do it even if I wanted to. I don't have access. I suppose there's someone somewhere who does have access to the containers running my code but I'm not sure who to ask and it would be easier to just merge a PR and then click the release button in the devops UI than to change code in prod.