views:

175

answers:

6

When it comes to code launches how do you handle developer access to the server? Do they have RDP access to the machines to deploy code and make changes? Are they only given ftps access to the servers docroots and any .NET configuration changes are handled by the sysadmins? Do the developers even have access to the production docrooots for deployment or do the sysadmins handle any code launches to the live servers?

+1  A: 

It depends, at our workplace the developers do everything. No systemadministrator says anything (since i am the systemadmin and a developer)

Bad part though is, lots of testing is occuring on the live enviroment which i am against and trying to stop but no luck yet.

My last workplace it was handle also by developers but in stages, lots of stages before going live.

Forser
+1  A: 

I've seen some of each over the years, and by far the best results have emerged when the developers have full access. Of course, all changes should still be documented and committed in version control and tested on a test system before deployment, and all that. The payoff in letting the developers into the production servers is when things go wrong. The developers are the ones who can see through the problem the fastest. In situations with heavy restrictions, I've seen critical one-line bug-fixes take days to deploy.

Glomek
sometimes even weeks!
Russ Cam
+7  A: 

The best setups I have worked with has a 3 level hierarchy:

  • DEV - Developers have complete access to these server(s).
  • STAGE - This is for developers and QA.
  • LIVE - Only sysadmins and build engineers touch these.

This will also depend on the company's budget and mindset.

hectorsosajr
+1  A: 

We use a mix of approaches. For applications where I am the primary developer and it is hosted on a dedicated server (or VM) I have full access to the web server. For applications where I am only developing a piece of a larger application, or the application fits within a larger frame work I get access to a directory where I can publish. For testing environments (or prototyping new services), it is typically full access. I have my own dedicated QA box that I have full access to for QA work. SQL servers are handled differently. I have a full install of SQL server locally that I develop against. I typically interact with a DBA to get a database set up on testing and production servers, but have full administrative access to the database, but not the server.

tvanfosson
A: 

I have full and complete access to every production server my company houses. But we are an extremely small company and I do a lot of the sysadmin work as well as all the development work.

Jeremy Reagan
A: 

I have full access to most of our production systems. There are a lot of problems that are easier for me to resolve than for IT. Though usually I don't make change to production unless absolutely necessary. If I do make a change I tell our admins so they can make note of it. We've tried doing it with limited access, but I work as part of a really small team so it isn't an option. Right now if we only gave the admins access 2 people would have to cover production problems. That is difficult with an oncall schedule.

wonderchook