The stepwise approach to software development no longer cuts it, not just because it’s too slow and too expensive, but most importantly because it fails to provide users with the mobile-ready, agile apps they need to achieve their organization’s goals.
In IT departments large and small, you can hear the sound of silos crashing to the ground. No longer do development teams, operations teams, or any other subset of a company’s technical operations work in isolation. The goal is to get everyone in the organization – from CTO to weekend help-desk operator – thinking end-to-end. Projects no longer have start and end dates. Timelines become nebulous, more flexible, and better able to adjust to fast-changing business conditions.
Welcome to the world of continuous integration, a key component of which is continuous delivery. No longer do development, testing, deployment, and maintenance happen as distinct steps in a predictable sequence. Now the process is a loop in which everything is happening at once, and everyone is working in a single team: managers, developers, operators, and end users participate at each stage of the software process.
The continuous delivery maturity matrix devised by Chris Shayan presents five stages of implementation: from novice to expert. Source: Chris Shayan, Atlassian
It’s no surprise the switch to continuous integration/continuous delivery has met with some resistance. In a February 1, 2016, post, Software Development Times’ Christina Mulligan writes that continuous delivery requires that developers “learn new skills, work in new environments and work at a new pace.” What’s the payoff? A closer connection to the customer, which ultimately translates into higher-quality software created faster and more efficiently.
How does continuous delivery make good on such promises? Think small. The development pipeline is populated with smaller releases whose failures occur more quickly and are easier to discover and fix. By failing faster and smaller, you’re able to try more new things without worrying about long-lasting effects; any negative feedback arrives almost instantly, and changes can be made nearly as fast.
The enemy of continuous integration/continuous delivery is anything that creates a bottleneck. The most likely place to encounter a bottleneck in the process is change management. According to CA Technologies executive Aruna Ravichandran, teams need to establish the value of every change based on user feedback, and they must make sure they’re always working on the most valuable components in a way that reduces risk.
According to Mulligan, making CI/CD work requires two things: a bottom-up approach driven by developers who are inventive and curious; and the orchestration, testing, automation, container, and other tools designed for small, agile applications. Counter-intuitively, bottom-up development only works when it is supported at the top. The CTO is going to insist on the auditing, traceability, reporting, and insight that are standard components of traditional IT operations.
According to a recent Continuous Delivery Survey, few organizations currently meet the three criteria of continuous delivery:
Martin Fowler’s description of a successful continuous-delivery process entails making sure software is always deployable, near-instant feedback on production readiness, and pushbutton deployments of any version to any platform. Source: Martin Fowler
IT Pro Portal’s John Esposito reports on the survey results in an April 6, 2016, article. Among the findings are that only 18 percent of the 600 IT professionals who responded to the survey believe their organization achieves all three continuous-delivery goals. The 41 percent of respondents who stated they have some continuous-delivery projects in place represents a 9 percent decrease from the number recorded in the previous survey.
The three most-common obstacles cited by respondents in their efforts to realize continuous delivery are a lack of corporate culture (57 percent), insufficient time to implement continuous delivery (51 percent), and lack of required skills (49 percent). It’s no surprise that lack of corporate culture was cited more often by people at large organizations, and lack of time was the chief deterrent reported by respondents from small companies.
It’s easy for IT managers to grasp the benefits of migrating their apps and databases to the cloud. Yet many IT pros continue to manage their cloud-based systems the same way they managed their in-house hardware. Logicworks’ Jason McKay writes in a March 14, 2016, article on The Whir that treating each server instance and network configuration as a “snowflake” duplicates an in-house management approach that is unsuitable to the cloud. Soon your cloud operations are suffering from the same unnecessary overhead that plagued your on-premises servers: slow updates, poor visibility, and cumbersome troubleshooting.
By contrast, treating infrastructure as code introduces such healthy software practices as easy accommodation of the inevitable requirements changes; frequent updates; automatic, continual testing; and more time spent coding than is spent documenting and putting out fires. McKay lists six characteristics of a healthy cloud-management strategy:
One of the greatest challenges to adopting a cloud-first approach to managing your company’s information assets is replacing the long-standing distinction between hardware and software with a singular view of apps and infrastructure as code that is in constant motion. The entire network – the apps, data, and platform they run on – is perpetually and simultaneously being developed, deployed, tested, and updated. As usual, the only constant is change.
