The connection between development and operations in IT means that developers and sysadmins get a lot more cozy in order to make sure that everything runs a great deal more smoothly. However, while this means breaking down a lot of bureaucratic barriers, it also means carefully examining how the organization uses this connection and what it means for the nature of the department (and its future.)

As a result, a question like “Should Developers Install Their Software Themselves?” becomes a big deal and such a question appeared on Ask Slashdot recently.

Should developers be responsible for installing the software they develop into production environments? What about System Test environments? I’m not a developer and I’m not all that familiar with Agile or DevOps, but it seems unhealthy to me to have software installs done by developers. I think that properly developed software should come complete with installation instructions that can be followed by someone other than the person who wrote the code. I’d like to hear opinions from developers.

The single opinion to this one appears to be a proper and resounding, “No,” but it also comes with a great deal of caveats that agree that developers need to work with operations in training them to use the software—but not to such a degree that developers hybridize with operations and form a chimera where neither tail nor head can be separated.

The training that development delivers to operations should appear in the form of documentation and configuration notes with the release (and perhaps some consultation that is then written back into the documentation) and not in the form of special dispensation.

“When the developers leave and there is no documentation and the thing blows up…” writes dremspider, making short work of the problem. “No one will know how it works. With handing the product and the documentation off to someone else this provides a final check on the documentation to ensure that the documentation doesn’t suck.”

As a developer, it’s important to produce and deliver a product that works once its loaded into the production environment by operations and does not need my constant tweaking; as a member of operations I want to be able to look into the documentation and have information on known bugs, error codes, and even configuration based on current hardware expectations to solve as many problems as I can without having to pick up the phone with support.

All of the above are true even when an enterprise IT department is the customer of a 3^rd party development team.

Installation is a process that Ops needs to handle; but Development still needs to understand it

Many of the commenters’ opinions didn’t focus on “should developers install the software,” but they did examine how the assistance of developers during the installation process could better allow them to understand what needed to be in the documentation and how to produce software that addressed the needs of operations during that process.

“There should not be a high wall between groups. Developers should not install it,” writes satch89450  in a comment, “but that doesn’t mean the developers are not there when QA or Configuration Managment or whoever installs it. As a long-time developer, I learned more from the struggling of other people with my software than all the scaffolding and test-bedding done in isolation.”

The test-production environment can only go so far to mimic the strain and stresses of the actual production environment. In the end, Operations is the end-all be-all of any product and while development engineered and prepared the software for that environment many things can go wrong there. As a result, DevOps should be a mixture of both Development and Operations even at the field position, but as a spectrum there is a point at which work is purely Dev or purely Ops.

With each gradient documentation and careful coding should be prepared by Dev based on an understanding of Ops expectations and hazards to make the install as painless as possible. Not all problems can be anticipated but having someone there to liaison—without becoming a micromanager or crutch—can readily bring the time to live and the cost of maintenance after going live down.

As with all things, the DevOps environment is a balance based on the skill sets of the Dev and Ops team and a careful consideration of what spheres each operate within.