But do you edit code on prod? I did for years on our two person high traffic startup. 1 billion application requests per month for one of them and orders of magnitude higher on the more recent biz. And I’d do it again. When you’re a one person dev and ops team with a smart partner to talk it through with, and where the cost of not making the rapid change is far higher than making a wrong change and rolling it back, do it. Every time. Fire up vim in the live box, edit and save. Different process if you’re horizontally scaled but similar idea.
I don’t do that anymore but I am working to get our dev team more in touch with operations now and to treat it less like the holy of holies and instead like a living breathing application that produces a ton of useful telemetry, even when it’s failing, that we can use to improve product and processes.
For a very small startup that seems like a good approach. I think the right approach differs greatly depending on the size of the company and the culture.
Me, having been employed mostly in medium sized companies, I only do so for absolute time and business critical issues. It gets the management of my back so I can focus and fixing it properly on my own time later.
For everything else. Nope. Everything needs to follow the proper processes. Nothing gets merged without code review. No, I can't directly deploy on prod. We will test on stage first.
You need to be firm or you end up with the slippery slope of "Can you just fix this small thing quickly?". No, sorry, please write a ticket we can discuss it next sprint. You can't let management know how easy deployments are these days, they must feel like it is a huge deal or they will mess up your whole sprint.
So the right approaches have more to do with company politics than what is technically the best and that is what is missing from this discussion. One of the most important priorities for a employed developer is to keep his peace of mind. At my current job I don't even have access to the prod. So even those time critical fixes are not possible. And it absolutely slows me down sometimes from discovering and fixing certain bugs but I sure as hell wont ask for access.
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
We 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.
I 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.
I 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
We did at my first web dev job. It was a dozen e-commerce sites all tied to the same backend and we would regularly turn Adsense down for a month while we worked on a new layout for one of the sites.
The owner was semi-tech savvy but not enough to be efficient and when I tried to explain I could just copy the site to a new server and clone the database he’d say, “we don’t have time for that.” Was like working at the McDonalds of web development (I think it was 2010 or 2011) and I don’t recommend it.
I don’t do that anymore but I am working to get our dev team more in touch with operations now and to treat it less like the holy of holies and instead like a living breathing application that produces a ton of useful telemetry, even when it’s failing, that we can use to improve product and processes.