By Robert Buccigrossi, TCG CTO

There are myriad approaches, tools, and goals associated with the term “DevOps”. Inspired by a recent webinar I attended that presented a rather abstract view of DevOps, I went on a hunt for a concise synopsis of the term that covered both the tools and philosophy. I found a number of resources, all with different perspectives. Combining information I found via Rackspace, Edureka, Simplilearn, AWS, and Atlassian’s websites, I arrived at the following summary.

The Problem: In many work environments, development is a separate team from operations. When development is done with a release, they “pitch it over the fence” to the operations team, who, once deploying to production, encounter many unforeseen problems. Any issue must be communicated back to and replicated by the development team (or fixed and pushed backwards by the operations team). This disconnection leads to process delay and reduced product quality.

DevOps – the Philosophy: At its core, DevOps is the philosophy that a single unified team is responsible for the development, deployment, performance, operations, and maintenance of a system. When developers are required to handle promotion, end-user, and security issues, they must “sleep in the bed they made” and are invested to improve quality and automate processes. Many practices associated with DevOps (automated deployment, unit testing, system monitoring and automated operations) are not the direct goal of a DevOps culture. Instead, the DevOps team naturally embraces these practices to eliminate disruptive issues, improve efficiency, and save time.

DevOps – the Process: With iterative development, we’re used to the Code -> Build -> Test -> Integrate -> Deploy cycle. DevOps adds “Operate”, “Monitor”, and “Plan” into the loop, which is typically depicted as a figure eight:

 Figure 1: The DevOps process

 

Issues and new requirements are identified in the operations of the production environment, which results in change requests (backlog items) that are prioritized and integrated into ongoing development sprints.

DevOps — the Practices: The DevOps team wants to catch issues as early as possible and has full control of the development, test, and promotion pipeline, leading to the incorporation of practices that improve promotion speed and reproducibility across environments:

• Automated Unit Testing – The ability to execute tests for every code commit
• Automated Security Testing – Automatically conducting penetration testing and static code analysis on builds (this elevates DevOps to “DevSecOps”)
• Continuous Integration – Automatically merging code from all developers to a central branch and deploying it to an integration environment for automated testing
• Continuous Delivery – Automatically packaging the software for deployment in a production-like environment (test and stage)
• Continuous Deployment – Automatically deploying software to production
• Environment Monitoring – Real-time monitoring of production for availability and performance

It is important to note that these practices are frequently associated with DevOps, but are not mandatory to meet the underlying DevOps philosophy.

DevOps – the Tools: To implement DevOps process and practices there are many families of tools (depending upon the OS and software environment). A common set (for Java development) is depicted in the following:

 

 Figure 2: Each step in the DevOps process can be supported by tools like those pictured here.

 

DevOps – an RoI-Based Iterative Approach to Practices and Tools: There has been an explosion of compelling automation technologies (e.g. the DevSecOps pages for AWS leads to a mountain of them). But every adopted technology represents a potential complication (risk of failure, learning curve, and cost) to the overall environment. While “containerization” and “infrastructure-as-code” are popular phrases in DevSecOps literature, when should an enterprise adopt specific tools and frameworks?

I encourage a return on investment (RoI) based, iterative approach to adopt and improve key practices. Many projects already have appropriate tools and near-neighbor technologies to automate testing, deployment, and environment configuration. For example, virtual machine images or Ansible scripts are easier to use with an existing system configuration than a seismic shift to Kubernetes clusters. By adopting tools iteratively and starting with the current environment, a DevOps team will be able to simplify the path to automation and improved efficiencies.

Summary: DevOps has a core philosophy — development teams should be responsible for operations and production support. The DevOps philosophy leads to processes and tools (such as continuous integration and automated testing) that result in quality improvements for both the team and end-users. By adding the philosophy that “security is a responsibility of every team member”, automated security scanning enters the pipeline, elevating the team into DevSecOps.

For more on emerging technology and IT management explored by TCG’s R&D lab, follow Robert Buccigrossi on LinkedIn.