Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Businesses Programming IT

Who Owns Deployments - Dev or IT? 152

txpenguin asks: "I am IT manager for a small software company. We host several generations of our applications in a fairly complex environment. Our systems are very much inter-dependent (clustering, replication, heavily loaded, and so forth), and bad changes tend to have a domino effect. Additionally, it seems that there are always those who need to be 'in the loop', but aren't aware of changes which affect them. There is a constant battle between IT and Development regarding who should handle the deployment of new code releases and database schema changes to production systems. Dev doesn't understand the systems, and IT does not know the code well. How do you handle this at your company? What protocols seem to work best? Can there be a middle ground?"
This discussion has been archived. No new comments can be posted.

Who Owns Deployments - Dev or IT?

Comments Filter:
  • by zrq ( 794138 ) on Wednesday December 13, 2006 @08:17AM (#17221188) Journal
    IT should own the deployments.
    Assuming the dev department does their job well, a deployment would not require any of the dev department's skills.

    Absolutely agree.
    If the developers do their job correctly, then a release should include a full set of install and migration instructions for IT to use.

    If IT do their job correctly, they should test the install on a separate system before deploying it live.
    If the install does not work 100% first time, don't tweak it, send it back.

    If the developers complain that IT didn't follow the instructions correctly, then the instructions were wrong.
    Send it back to the developers to write better instructions.

    If all goes pear shaped on the live system, IT should have a full set of (tested) instructions on how to rebuild the system from scratch.
    If the developers can't supply those instructions, then you don't know what you have.

    Ok, I know this is nice in theory and difficult to acheive in practice, but both teams should be working towards this as their goal.

  • Mod Parent Up (Score:2, Interesting)

    by A. Lynch ( 17937 ) on Wednesday December 13, 2006 @08:30AM (#17221292) Journal
    This scenario has always avoided the "pissing match" that inevitably occurs between Dev and IT, in my opinion. Clearly defined roles.

    In a previous shop, we treated our in-house developer code releases like any other vendor release. Just because some code was written by the guy down the hall, shouldn't mean that I can't ask for the same level of documentation/support I get from another Tier 1 vendor.
  • by negyvenot ( 582011 ) on Wednesday December 13, 2006 @08:33AM (#17221318)
    I could not agree more. We have a fairly large projects where the devs do the deployments and I can tell you its all a big mess. Since the devs have the right to do deployments, naturally they can make small changes to the production environment invisible to the operation team. Since there are quite some incidents occuring on the production environment, the dev team tends to fix the problems on the production environment on the spot because "oh, its just a matter of fixing this and that", therefore the acceptance environment is not used for testing as it should be.

    Although I know it would put considerabe workload on operation team to take over deployments, I'm sure there would be less incidents and more stability on the production system. sure the deployment process would slow down updates, but would give a chance for a more transparent and controllable process with clear ownership of responsibility, etc.

    Now that the project is for more than half a year in production, I see no real chance to change the deployment ownership, but still I wish it could be done.

If you want to put yourself on the map, publish your own map.

Working...