...or do you have to go through someone else (a person who manages the servers) to get your code deployed?
I understand the policy of not letting everyone log onto a live production server but I would like the ability to have access to my code, database and files once they are live.
How is it for everyone else?
It all depends on what procedures the company has in place. Some are more flexible than others. Our organization is moving away from developers having access to the production environment. Now everything has to follow the process of QA and then operations (who take care of the deployment and maintenance of the code). I think you'll end up with less incidents, but a longer bug fix time.
At the last place I contracted for, there is a specific group of people responsible for deployment and configuration on the production servers.
All your code had to be checked in to the vcs and this is where they got the code to deploy. So you don't have "access" to make changes to the code once it goes live. They deployed new/changed code twice a week unless it was an emergency deployment.
I just deployed something to a live environment today. I also have access to the live database.
This has been known to cause some epic failures in the past. Sometimes somebody dropped a table on the production environment instead of a development environment. However, I see little advantage in another person doing the releasing, especially when he is not that acquainted with the software.
The ideal release procedure flow is as follows (in my little world):
Depending on how strict your company is, the developer may or may not have access to the live release, especially if it's a big company.
Every environment is slightly different. In comparison, you have to decide what works for you. Amazon for example makes their developers own their own code, which some developers hate, but it is a feature of that environment that keeps bug counts low (when was the last time you saw a bug on amazon.com?).
Others want a tighter QA process so create an operations department to look after deploys, but I've found they tend to create an atmosphere of negativity in the company: they are rewarded by justifying their role, which entails pointing out and supporting the bad things in the World. If the devs are good at their job, resentment can creep in if their pay is in any way performance-related.
Personally, I tend to prefer to look after the whole stack, but increasingly am moving to providers that allow me to worry less and less about hardware (EC2, Heroku, etc.), and to focus more on functionality in the apps. I personally like owning the code and the bugs, as it means I am demonstrably motivated to keeping bug tickets down - every open ticket is a delay to the new functionality I want to work on.
Each to their own.
Having a configuration management group, or someone other than the development group deploy code to the production environment have it's advantages. Most of which help enforce a rigor and audit trail of releases. Ideal the configuration management team should release code by scripting. The script pulls from the code repository for a certain tag, and releases to a certain server. Doing so minimizes mistakes along the way.
I think the development team should have read only rights to production data, and ability to see any log files. This allows for easier debugging of problems. If a new version of code also requires database updates, the configuration management team should also be deploying those changes, by script of course.
Answers above mentioned development and testing environment. It is also quite important to have dedicated, separate build server that is not used for development. It pulls source code from repository, compiles and creates distribution (in Java world EAR or WAR file) that is then deployed to testing environment etc.
This build server can also host CI environment and perform regular automated daily builds.