Whenever the responsibilities of designing, coding, testing, implementing, and maintaining internal software are split across two or more groups you end up with no one person who understands the entire system top to bottom as well as the entire set of requirements for all phases. IT should be there to keep user's desktops running, run internal email and ticketing systems, etc.
Dev should be there to gather requirements, architect (both software and hardware), and implement internal software. They should also then own all of the deployment maintenance and management of all production systems running the software they have written. This forces developers to think about real production needs, scalability of processes during deployment, etc. It also ensures that the people with the most technical knowledge and understanding of the system are the ones responsible for its maintenance and that they have a large stake in making it reliable as they will be the ones getting paged at 2am when the system crashes.
Finally, as to the actual deployment, it shouldn't really much matter who does it as it should be a completely automated task which takes no more than a few minutes and any monkey could do. Rollback to previous versions should be equally automated.
Many comments on this thread are from IT guy's saying 'oh IT should own it, of course!' but please think things through and don't blindly accept the conventional wisdom. The only reason IT needs to own it in most shops is because of the broken separation of responsibilities that is already setup. If IT are the people who are getting fired when servers are down and who are getting paged and woken in the middle of the night then yes, of course they should be the only ones mucking with the bits on the servers as it's their neck on the line. However, the reality is things would be much smoother for both teams if dev's were the ones with their necks on the line and they were responsible for the systems they are coding for. As a still small company you have a chance to get this right.
The final thing to consider is that good Dev's hate working for a company where they can't get work done and can't make unnecessary changes because of too much process and too many political barriers where the all too often less skilled workers in IT are trying to control everything. If you want to recruit top dev talent then you need to let your dev's control their own destiny and take responsibility for their own systems.
Slashdot Mirror
Whenever the responsibilities of designing, coding, testing, implementing, and maintaining internal software are split across two or more groups you end up with no one person who understands the entire system top to bottom as well as the entire set of requirements for all phases. IT should be there to keep user's desktops running, run internal email and ticketing systems, etc. Dev should be there to gather requirements, architect (both software and hardware), and implement internal software. They should also then own all of the deployment maintenance and management of all production systems running the software they have written. This forces developers to think about real production needs, scalability of processes during deployment, etc. It also ensures that the people with the most technical knowledge and understanding of the system are the ones responsible for its maintenance and that they have a large stake in making it reliable as they will be the ones getting paged at 2am when the system crashes. Finally, as to the actual deployment, it shouldn't really much matter who does it as it should be a completely automated task which takes no more than a few minutes and any monkey could do. Rollback to previous versions should be equally automated. Many comments on this thread are from IT guy's saying 'oh IT should own it, of course!' but please think things through and don't blindly accept the conventional wisdom. The only reason IT needs to own it in most shops is because of the broken separation of responsibilities that is already setup. If IT are the people who are getting fired when servers are down and who are getting paged and woken in the middle of the night then yes, of course they should be the only ones mucking with the bits on the servers as it's their neck on the line. However, the reality is things would be much smoother for both teams if dev's were the ones with their necks on the line and they were responsible for the systems they are coding for. As a still small company you have a chance to get this right. The final thing to consider is that good Dev's hate working for a company where they can't get work done and can't make unnecessary changes because of too much process and too many political barriers where the all too often less skilled workers in IT are trying to control everything. If you want to recruit top dev talent then you need to let your dev's control their own destiny and take responsibility for their own systems.