Who Owns Deployments - Dev or IT?

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?"

Re:Speaking as a developer

[arachnoprobe]

I think thats a good comment. That would also force the Dev Team to write a good documentation and spec.

Production Services

[bihoy]

This is why many companies start a Production Services team. Generally this means the hiring of a Build and Release Engineer or Manager who has an IT background and an understanding of Software Development.

The alignment of the Production team varies. At some companies they report to the development organization (e.g. to the Manager or Director of Software Engineering) and at other companies they report to Quality Assurance.

I would suggest that you check out the site: http://cmcrossroads.com/ [cmcrossroads.com]

From a Dev Guy

[BishonenAngstMagnet]

I work in my city (population approx. 200,000) government's IT department as a developer. As someone else mentioned, the best way to handle code deployment is over a three-tiered system. At DIT, we have Dev, Stage, and Prod for the Internet, Intranet, and Applications sites. Developers should be given full read/write access to dev, in which they do all of their work. In no way should the world, nor the client, see dev. Upon completion, we promote our work to staging (via sending a promotion request, or doing the promotion yourself, if you happen to have access to staging like myself). At staging, the client (for us it's 99% internal work, so someone else within City Hall) can review the work, request additional changes, etc. After the staging process is done, a request is sent to the guys in ops (IT) to promote to production.

Basically, to answer your question: IT should handle code deployment, but developers should be involved in the process.

Re:Dev owns the deployments

[MyLongNickName]

The developers need to own the entire product,

So what about someone like me in the banking industry? You have any idea how long and hard the auditors will bitch if there isn't a separation of duties? Technically the developers are not to have ANY access to the production environment above that of an end user. (operative word being technically)

Re:Middle ground

[mjpaci]

My company (~2,500 ppl) has moved to this model. However, we have dedicated "deployment engineers" who take the developers' documentation and follow it to a T. If there is an issue, they roll back. At first nobody liked the idea, but as time progressed it has started to work well. The deployment engineers were taken from the server teams and the DBA team and formed into a new group of about 10 people.

--Mike

Re:Speaking as an IT coordinator

[cerberusss]

Since there are quite some incidents occuring on the production environment,

Well, it obviously doesn't matter enough for your customers to have those projects 24/7 online, otherwise things would be different. So why bother?

In a previous job, we had three groups: development, system administration and application management & testing. Development would put the deployment files in a share and then sysadmin would take over, deploying it to acceptance and production if fiated by application management. If something went wrong, development would create new deployment files in a share. Sometimes when deployment was quick 'n' dirty, a developer would walk through the deployment with a sysadmin.

However, it took a very strong head of sysadmin. His manager would try to order quick 'n' dirty things, but the head of sysadmin would take it up higher to the boss. I heard once that when he got refused by the boss, he walked straight out of the door saying he'd quit. Boss ran straight after him :-)