In today's digital age, business innovation is largely driven by software. To win, serve, and retain their customers, enterprises must release application updates at an increasingly faster pace. A great idea, killer functionality and a robust technology are all as important as ever, but they don't mean much if you can't get your code to your end users in a fast, predictable manner with high quality.
Your Pathway to Production -- call it PtP -- is the path that your code takes from developer check-in all the way to a successful release. It spans the entire organization and comprises all the different stakeholders, teams, processes, tools, and environments involved in your software delivery. This is how your organization delivers value to the market.
Increasingly, we see that organizations that become better at streamlining and accelerating their PtP are better equipped to compete and win in today's economy.The maturity, speed, and quality of your software release processes have become a key differentiator and a competitive advantage for businesses today.
Devops and ARA: Paving a better PtP
Devops and ARA (Application Release Automation) have emerged to help organizations become better at delivering software, allowing for greater speed and agility while mitigating the risk of software releases.
Devops has huge business benefits: Statistics show that organizations that practice devops outperform the SMP500 over a 3 year period, high-performing IT organizations have 50 percent higher market cap growth, and so on.
In order to remain competitive and meet consumer demands, enterprises across the board are adopting devops to optimize their PtP. Just as you would invest in designing the right functionality for your product or defining a winning go-to-market plan, organizations now invest in optimizing and (re)designing their PtP to enable innovation.
The implementation of devops in large organizations comes with a unique set of challenges. Enterprises often need to support large volumes of distributed teams and multiple applications/product releases. In addition, regulatory and governance requirements, supporting legacy systems, tool variety, infrastructure management, and complex internal processes further compound these challenges.
Devops in the enterprise: Starting small, dev is leading
Agile methodologies, adopted by many software organizations, have been largely focused on development, QA, and product management functions, and less on the PtP once the software has been authored.
As a continuation to Agile, devops also started as a very dev-driven movement (despite the "ops" in the name). Dev teams were quicker to adopt these practices, as they were eager to find a way to get their code into production faster. Ops were traditionally more hesitant to adopt devops, seeing the increased velocity and speed as possible risks.
The majority of devops implementations today still start as grassroots initiatives in small teams. And that's OK and is a good way to show early success and then scale. Increasingly, alongside these bottom-up efforts, we're seeing a shift toward devops being a company-wide initiative, championed both at the executive level and team levels.
The next phase: Scaling devops, ops takes center stage
One of the biggest challenges for large enterprises is the siloing of people, processes, and toolsets. Often, one or more of these silos may be adept at understanding and automating their piece of the puzzle, but there is no end-to-end visibility or automation of the entire pathway. This leads to fragmented processes, manual handoffs, delays, errors, lack of governance, etc.
Since the PtP spans the entire organization, enterprises are realizing that optimizing it is not a disparate set of problems, but requires a system-level approach. The evolution of devops is toward scaling adoption across the entire enterprise to cover the end-to-end PtP. This removes friction by automating all aspects of your delivery pipeline, in the pursuit of creating predictable, repeatable processes that can be run frequently with less and less human intervention. By achieving consistency of processes and deployments (into QA, staging, production) throughout the entire lifecycle, you're in fact always practicing for game-day, and hardening your devops practices as you optimize them.
As part of this process -- as devops matures and becomes mainstream in enterprises (and as it becomes more critical to their operations) -- devops practices are hardened to take into account more ops requirements for releases: mainly around manageability, governance, security, and compliance.
Talking about enterprise control is no longer a bad thing or something that may be viewed as hindering devops adoption. devops is about enabling speed while ensuring stability. Similar to children maturing, now that we've grown and learned to walk (faster), it's time to learn to be more responsible.
As with the software your organization is developing, it's time to harden your devops practices to scale adoption throughout your end-to-end process across the organization. Hardening doesn't mean sacrificing speed or experimentation; it means your devops is getting ready for prime time!
Hardening your devops implementation
You want to design your underlying tools and processes along your PtP in a way can scale across the enterprise. This requires balancing team ownership and collaboration, with supporting the needs of the organization for checks and balances, standardization, and system-level visibility and control.
While you would likely still start local and gradually roll out across different groups as you optimize, be sure to always think global. As you analyze and (re)design your PtP, you need to always consider: How do I scale this across all teams, applications, releases, environments and so on.
First, take some time to map your end-to-end PtP. From my experience, organizations often are not even aware of the entire path their code takes from check-in, through build, testing, deployment across environments, etc. Be sure to interview all the different teams and stakeholders until you have a detailed documentation of your cross-functional pipeline(s), including all the tools, technologies, infrastructure, and processes involved.
Then, take a look at the bottlenecks. For example: waiting on VMs, waiting on builds, configuration drifts between environments, failed or flaky tests, bugs making it to production, failed releases, errors or lags due to manual handoffs between teams or tools, etc.
As you redesign your pipelines to eliminate friction points, here are some things to consider on your journey to harden your devops practices to support stability and scaling across the organization:
- How do I ensure security access controls and approval gates at critical points along the pipeline?
- How do I guarantee visibility and auditability so we have real-time reporting of the state of each task along the pipeline, and a record of exactly who did what/where/when?
- What security and compliance test (or other tests) must all processes adhere to in order to move through the pipeline and into production?
- How do I standardize as much as possible on toolchain, technology, and processes to normalize my pipeline to allow reusability across teams/applications and save on cost?
- How do I still enable extensibility and flexibility to support different needs from various teams or variants of the application?
- Can my chosen devops solution orchestrate and automate the entire end-to-end pipeline?
- Can my implementation support bi-modal IT, enabling traditional release practices and support for legacy apps, as well as more modern container/microservices architectures and CD pipelines?
- Can I support both simpler, linear, release pipelines, as well as complex releases that require coordination of many inter-dependent applications and components into many environments?
- Is my solution future-ready and flexible enough to be able to plug in any new technology stack, tool, or processes as the need arise?
- As I scale, can my implementation support the velocity I'm expecting across the organization?
- Setting up one pipeline for one team/release is easy enough, but how do I onboard thousands of applications?
While optimizing your tools and technology to scale devops adoption is important, it is only half the battle. Above all, devops is a mindset, and cultural shift takes time. Remember that change doesn't happen in a day, and that you're in it for the long haul.
As a community, we started with asking why we should even bother doing devops. After establishing momentum and proving the ROI of devops, the discussion is gradually evolving to how we get devops right in large enterprises: what are some of the patterns for success, and how can we effectively scale so that the entire organization can reap the benefits.