The term āDevOpsā comes from combining two different words, “development” and “operations.” And just like its name, DevOps seeks to combine two different sets of IT practices ā software development and software operations, the work of the system administrator.
The idea is to speed the development process and eliminate the wait-time between development of the software and when it goes into production. This, of course, requires the developer to take more of a hands-on approach when deploying his or her technology, watching out for problems as the software is installed and put into operation. On the other side of the coin, the operator may have to go back into the development environment to fix some issues as they occur.
This approach has garnered many adherents, though also its fair share of criticism. One of the things that is potentially a roadblock for uptake of DevOps in the enterprise has been the internal culture of many organizations. With so many new ideas and tools out there, it can feel like your company doesnāt get it at all, and even perhaps fears DevOps.
While DevOps tools are available, ultimately, “adopting DevOps doesnāt start with adopting tools ā it starts with adopting the underlying values of the DevOps community,” InfluxData’s Katy Farmer wrote.
The biggest challenge with DevOps, Farmer notes, is the facilitation of communication. Most of the talks on the conference circuit are about enabling better communications in the DevOps processes. This is not surprising, given the amount of communication that must go on between team members and different teams, and between the developers and the end users.
Another aspect being discussed in DevOps circles is that of how to add security into the process. Adherents have long preached that security should be baked into the development process, not merely “bolted on.” Working security into the mix has resulted in an extension to DevOps, called DevSecOps.
