Devops is one of those fancy contractions that tech folks just love. One part development or developer, and another part operations. It imagines a blissful marriage where the team that develops software and builds features that fit the business, works closely and in concert with an operations and datacenter team that thinks more like developers themselves.
In the long tradition of technology companies, two separate cultures comprise these two roles. Developers, focused on development languages, libraries, and functionality that match the business requirements keep their gaze firmly in that direction. The servers, network and resources those components of software are consuming are left for the ops teams to think about.
So too, ops teams are squarely focused on uptime, resource consumption, performance, availability, and always-on. They will be the ones worken up at 4am if something goes down, and are thus sensitive to version changes, unplanned or unmanaged deployments, and resource heavy or resource wasteful code and technologies.
Lastly there are the QA teams tasked with quality assurance, testing, and making sure the ongoing dearth of features don’t break anything previously working or introduce new show stoppers.
Devops is a new and I think growing area where the three teams work more closely together. But devops also speaks to the emerging area of cloud deployments, where servers can be provisioned with command line api calls, and completely scripted. In this new world, infrastructure components all become components in software, and thus infrastructure itself, long the domain of manual processes, and labor intensive tasks becomes repeatable, and amenable to the techniques of good software development. Suddenly version control, configuration management, and agile development methodologies can be applied to operations, bringing a whole new level of professionalism to deployments.