Embracing continuous delivery to power the programmable enterprise

“Move fast and break things” with DevOps has become a popular Silicon Valley mantra during the past few years. DevOps empowers developers to quickly ship code and holds them accountable for operating their software. As DevOps becomes the new norm within Silicon Valley, enterprises outside the Valley have begun to look on with a mix of intrigue and terror.

Some organizations have held to enforcing the ITIL (Information Technology Infrastructure Library) method of ITSM (IT service management) and shied away from using DevOps. These organizations maintain that the segregation of duties is a non-negotiable requirement for compliance, and developers should never be allowed to ship code directly to production.

Other enterprises, such as Intuit, CSAA, NBCUniversal, Rally Software, and Family Search, have wholeheartedly embraced DevOps. These organizations found ways to smartly navigate compliance issues, and in the process, accelerated their development velocity, shortening the time needed to take ideas from whiteboard to customer implementation. These enterprises are now well on their way to becoming “programmable enterprises.” 

The programmable enterprise

The programmable enterprise deconstructs its systems into APIs and microservices. Once deconstructed, those APIs and micro-services can be quickly assembled into new business capabilities, such as a new web store that reuses internal services like customer lookup, billing; and leverages external services like card processing or shipping.

When programmable organizations combine these with a culture of commercial intensity, they innovate faster, and more importantly, accelerate delivery of new value to their customers. The result is sustainable business differentiation when compared to enterprises holding to traditional IT service management.

Continuous delivery

Becoming a programmable enterprise allows organizations to continuously deliver new capabilities to the market. To the torch bearers of traditional IT service management, this sounds dangerous. It isn’t. With continuous delivery, enterprises release code when it has passed all the checks rather than on an arbitrary date. Those checks ensure that there are no security exposures, that the services are resilient and that there is no risk to revenue or the brand.

A continuous delivery process typically conducts the following:

• White box analysis focuses on analyzing the source code for issues. Steps include:
• Adherence to coding standards, using tools like SonarCube to ensure there are no “blocker” defects.  In other words, scanning the source-code to ensure that developers aren’t doing things that are obviously bad, like executing System.exit(0) in server-side code. The scan also ensures structural correctness, like appropriate level of comments and minimal cyclical complexity.
• Static application security analysis that examines the source code for vulnerabilities, like SQL injection and cross-site scripting.
• Appropriate unit-test coverage and successful execution of those unit tests.
• Dependency analysis, detecting and mapping upstream and downstream services. This can be used for both impact analysis as well as fine-tuned automated testing services that only run tests on components effected by a change. 

• Black box analysis focuses on running a service and testing it through external interfaces. Steps include:
• Dynamic security testing that essentially auto-hacks the service.
• Performance regression testing that can identify degradations in performance and scalability.
• Injecting failures for resilience testing, also known as “Chaos Monkey.”
• Automated user-acceptance testing that can identify regressions in business function.
• Portability analysis, essentially running and testing the service with alternative run-times to ensure there is no vendor lock-in.

• Triggered code-reviews could be the last step in the process. In this step, the automation has filtered out most of the problems, but there is still a need for peer-review of the code. Some triggers include whether there are changes to a critical-path component or whether a developer checked in more code than expected.

• Operational readiness becomes an inherent part of the process. IT and Security Operations teams monitor and react to the black box tests, including dynamic, application security and resiliency tests, to exercise the incident response and triage processes.

Continuous delivery and architecture as code

Continuous Delivery also enables organizations to “shift left” – to catch and remediate problems earlier in the software development life cycle, rather than waiting until the end of the release, or worse, in production. The more robust the continuous delivery process, the more trust the organization have in the quality of the code as it goes live. When combined with “architecture as code” principles, organizations trust in both the software and the underlying systems. As a result, those organizations can quickly and responsibly deliver new capabilities to market.

From an application developer’s perspective, this process must be frictionless. False positives, where the process identifies defects that are not issues, erode credibility and lead to organizational disillusionment.

Ultimately, the wing-to-wing experience from an application developer’s perspective should be:

• The app developer checks in code.
• The code is automatically deployed into the build cloud, leveraging the development pattern within the Architecture-as-Code library, and run through a series of automated white box checks.
• If the code fails the white box checks, the build fails, and the application developer is notified with details on what failed, and possible recommendations for how to remediate.
• If the code passes the white box checks, it is automatically deployed into the test cloud, leveraging the QA / production pattern within the architecture-as-code library, where black box tests are executed.
• If the code passes the black box checks, it is marked as ready for production, and in certain cases the code is automatically deployed into production. In other instances, the production deploy will require additional approvals.
• Throughout this entire process, data is collected and conveyed to the development managers via an analytics dashboard. This allows managers to have a better idea of developer performance and leads to better, more informed management. 

• When combined with Architecture-as-Code principles, the only difference between test and production should be the user IDs, passwords, resource connections, and IP addresses.

Continuous Delivery allows an organization to become a programmable enterprise, putting data at the fingertips of developers and decision makers, providing greater transparency into the development process and ensuring that IT teams can responsibly deliver new capabilities, at a high velocity, to the business. At this point, foregoing DevOps and continuous delivery for traditional IT service management, like ITIL, is more than a difference in philosophy — it’s a disservice to your business.