The term DevOps has exploded as a technical buzzword in the last few years. A search on any tech jobs board will reveal a multitude of posts for DevOps engineers, almost as many as ‘Cloud’ engineers or developers. The job descriptions apply the DevOps term to a wide variety of different tasks and responsibilities, depending on the organization.
Historically, most organizations used clearly defined and distinct Developer and Operations teams.
These teams were very much separate, with minimal overlap and communication.
The deployment methods used by these organizations typically involved “throwing the code over the wall”: once the Development team decided their code worked, they packaged it up with some documentation and handed off to the Ops team to deploy and maintain. If the code did not work, the Ops team simply threw it back over the wall with commentary along the lines of “it doesn’t work!”
Much of this resulted from the lack of thought given to scalability.
Developers wrote the code on one platform, despite the fact that Ops would test it on another platform.
In an attempt to keep Development and Operations teams from playing a never-ending game of code volleyball, QA teams stepped into the middle, leveraging their development background to more easily communicate errors back to the development team and reducing the likelihood of the Ops teams receiving faulty applications.
But adding the QA team also added certain complications to the deployment process.
In addition to the original wall between Development and Operations, now there’s a second wall between QA and Ops. Each team also deploys code in their own environments, which don’t necessarily stay in sync without automation to keep them consistent.
If there are even minor differences between environments, an application that works perfectly in Dev might possibly pass QA, but could then still fail catastrophically when the Ops team deploys it to Production.
The DevOps model changes the legacy code deployment strategy by combining Dev, QA, and Ops into an integrated organization, removing the walls and barriers, and softening the distinction between these teams.
Environments are treated as a part of the code and kept consistent through all aspects of the deployment while using similar version-control tools.
Could your business use the DevOps culture? Contact us.
