In the end, it really depends on your individual department's policies. My department uses version control. We use CI. Dev -> Prod takes as long as it takes the tests to run.
Admittedly, we've managed to fly under the radar with respect to all the arbitrary processes that have been developed. The ideal "process" involves a 1 year dev cycle and filling out a lot of forms every time you even think about changing the production environment. Ultimately, you can follow the letter of the law without requiring too much effort. We install our own Linux distribution in /usr2 on all of our servers so that we don't have to get the dudes in India to install packages for us. We use Redis and SQLite (for some apps) instead of the "official" database, Sybase, so we don't have to fill out requests. The only request that's fast is, "can you please reboot server x", so we have a "firewall rules" script that runs out of rc.local as root. If we need to make some change, we just edit that script, ask for a reboot, and watch something get done in less than a year.
What you have to realize is that the people that design technology processes at big "non-technology" companies don't know anything about technology. It's a job that you get because you failed at being a janitor and they didn't have the heart to fire you. So the processes they design deserve approximately zero respect. The rules are there so they can tell their bosses that they made some rules to prevent all those developer monkeys from doing anything evil. But in reality, they wouldn't know a computer program if it hit them in the face, so they don't actually have the ability to enforce the rules. Nobody has ever been fired for being grossly incompetent, so it follows that nobody has ever been fired for being grossly competent either. Since it's easier to be competent, and you won't get fired for it, that's what we do.
(BTW, the processes would never protect against a malicious internal developer. The reason is that w there's no process like "someone that knows something about programming must review your code". Instead it's stuff like, "laptops must be triple-encrypted" and "you must not use emacs, as it's a 'non-approved' computer program".
You may not be allowed to bring in malicious code, but you can write it in house. A good example was a friend that needed ssh on a Windows server. That's not allowed, so he wrote a program that binds a TCP sockets and execs, with full privileges, every line it receives from any client. That's 100% OK, because there's no way in-house software can be insecure! The system works!)
I will agree with his point about hiring, though. We ask for some code on the whiteboard questions, and 99% of candidates epic fail it. (Our question is: given that F(n) = F(n-1) + F(n-2) and F(1) = 1 and F(0) = 1, write a naive function in your favorite programming language to calculate F(n). And people can't do it!)
We recommend against their hire, but someone always overrules us and then they get hired. As a result, every time we have an open position, the team gets progressively dumber. That's because those janitor-rejects I was talking about in the previous paragraph think that anyone that says they are a programmer is qualified to be a programmer, and they get a raise if they "increase their headcount".
I am getting tired of this and will probably leave soon, but some people apparently like it. I might like it if they didn't lie to me about how much I'd be paid and then lie about the reason for not paying me.