devopsy.kinsta.cloud

Tag: Continuous Delivery Foundation

  • CDEvents Simplifies AI-Ready Developer Platforms

    CDEvents Simplifies AI-Ready Developer Platforms

    Internal developer platforms have become a tangled web of orchestration tools, CI runners and deployment systems that rarely speak the same language. Every new integration adds another translation layer, and as AI-driven automation starts to plug into those pipelines, the lack of a shared vocabulary for what is actually happening across the software delivery lifecycle becomes a real bottleneck. Without a consistent way to describe build, test and deploy events, both humans and agents are left stitching together logs and webhooks from systems that were never designed to interoperate.

    Dadisi Sanyika of the Continuous Delivery Foundation sat down with Mike Vizard to walk through how CDEvents is tackling that fragmentation. CDEvents defines a common event specification — essentially a standardized set of receipts that tools like Jenkins, Tekton and other delivery systems can emit as work moves through the pipeline. That shared semantic layer gives platform teams a reliable way to wire heterogeneous tooling together without writing custom adapters for every combination.

    Sanyika digs into Conduit, a project aimed at reducing the integration burden that platform engineers carry when assembling internal developer platforms. Rather than forcing teams to bolt together pipelines, observability and policy tools piece by piece, Conduit leans on CDEvents to provide the connective tissue. He also lays out how natural language interfaces, semantic orchestration and open source interoperability come together to make those platforms more accessible — and more amenable to AI agents that can reason about what is moving through the pipeline.

    The bigger payoff is what becomes possible once delivery events are standardized. AI-enabled DevOps platforms can finally act on trustworthy, structured signals rather than improvised log scraping, which opens the door to smarter automation, better feedback loops and developer platforms that adapt instead of calcify. Standards work like this rarely makes headlines, but it is the kind of plumbing that determines whether the next wave of AI tooling in software delivery actually lands.

  • CDF Report: Steady Growth in Number of Jenkins Jobs Run

    CDF Report: Steady Growth in Number of Jenkins Jobs Run

    The Jenkins project that operates under the auspices of The Continuous Delivery Foundation (CDF) reported this week that over a two-year period, usage of pipelines grew 79%, with total workloads defined in the continuous integration/continuous delivery (CI/CD) platform growing 45% over the same period.

    Based on analysis conducted from June 2021 to June 2023, the report found the number of jobs defined increased from 27,105,176 jobs to 48,625,398 jobs per month. The number of all jobs defined on Jenkins increased from 50,785,205 to 73,746,418 jobs per month (45%).

    Sacha Labourey, a member of the governing board for the CDF and chief strategy officer at CloudBees, a provider of commercially supported instances of the open source Jenkins CI/CD platform, said it’s clear that more applications are being constructed by more organizations than ever using DevOps workflows.

    At present, the CDF reported there are now more than 600 active contributors to the Jenkins project. That level of support has made it possible for Jenkins to become a standard CI/CD platform. DevOps teams know there is a substantial open source community they can count on for support, said Labourey.

    The challenge now is how to centrally observe DevOps workflows to accelerate application development while at the same time giving developers more freedom to innovate. Platform engineering principles represent an opportunity to achieve that goal, as long as developers still have an opportunity to innovate and collaboratively address bottlenecks in DevOps workflows as they occur.

    The platform engineering team should be observing processes and proactively making recommendations and define a set of guardrails that ensure DevSecOps best practices are followed, he added.

    Otherwise, application developers are likely to view platform engineering as another effort by centralized IT teams to take power away from the developer, noted Labourey.

    Striking that balance is especially critical as the number of cloud-native applications being built and deployed alongside classic monolithic applications has significantly increased, he added. DevOps teams need to be able to centralize observability of what are two distinct styles of application development that tend to occur at a significantly different pace from one another, Labourey said.

    Hopefully, advances in artificial intelligence (AI) will make it easier for DevOps teams to strike the right balance between management and innovation. In the meantime, however, as the pace of application development continues to accelerate, each DevOps team will need to determine how best to evolve their existing workflows. That’s especially critical at a time when economic headwinds are requiring organizations to find ways to increase existing developer productivity rather than hire or contract additional developers.

    In the meantime, it’s apparent that DevOps, as a methodology for building and deploying applications faster, is here to stay. The next major challenge is finding a way to achieve that goal at levels of scale that require automation everywhere from the network edge to the cloud.

  • CDF Marries Emporous Repository to Ortelius Management Platform

    CDF Marries Emporous Repository to Ortelius Management Platform

    The Continuous Delivery Foundation (CDF) has added the open source Emporous repository for software artifacts to an Ortelius platform for managing the software artifacts that make up a microservice.

    Ortelius was originally created by DeployHub and subsequently contributed to the CDF, which also oversees the development of the open source Jenkins continuous integration/continuous delivery (CI/CD) platform.

    Emporous is based on a Universal Object Reference (UOR) conceptual model that enables dynamic schema registration and decentralized content-addressable reference of a wide spectrum of software artifacts. Originally developed by Red Hat, Emporous will now be managed as a sub-project within the larger Ortelius incubation-level project by the CDF.

    DeployHub CTO Steve Taylor said this integration would make it simpler to store, organize and search metadata related to software artifacts, along with the artifacts themselves, within the context of the Ortelius platform for managing microservices.

    Ortelius provides insights into the relationships and dependencies between different software components and applications. It does this by collecting and aggregating pipeline data from multiple sources within a software supply chain. Emporous will be incorporated within Ortelius to enhance metadata search capabilities and provide a single repository to store any type of artifact, from containers to jar files. It will now also be able to store metadata and also the artifacts themselves within the same Emporous catalog.

    Those capabilities will significantly improve security and compliance reporting across a software supply chain, added Taylor. DevOps and cybersecurity teams will be able to automatically apply and enforce supply chain policies and procedures, he said.

    DevOps teams need a way to aggregate all the data from the various tools they use and the data must be easily searchable. Armed with those insights, it should become simpler to surface insights into, for example, which components of an application contain known vulnerabilities.

    In the longer term, IT organizations will be able to apply machine learning algorithms and other forms of artificial intelligence (AI) to automatically surface insights that will enable DevOps teams to automate workflows, said Taylor.

    Microservices-based applications are considerably harder to build and manage than monolithic applications, but they are also easier to maintain because individual microservices can be ripped and replaced.

    Most microservices today are built using containers, but there are also microservices that are written in Java, for example. In some cases, developers view monolithic applications as being a large, less flexible microservice that they invoke via an application programming interface (API).

    There’s no doubt that the rise of microservices made application environments a lot more complex. The tools needed to simplify the management of the next generation of applications are finally starting to become more widely accessible. In theory, the number of organizations that can successfully build and deploy these types of applications should steadily increase in the months and years ahead.

    In the meantime, there’s clearly still plenty of work that needs to be done to improve the overall state of software delivery. A recent CDF survey found only 22% of respondents were using continuous integration and continuous delivery (CD) to automate the building, testing and deployment of code in a production environment. As CD becomes more distinct from CI, however, the number of organizations that can achieve that goal when deploying microservices-based applications should steadily increase.

  • CD Foundation Announces State of CD in 2022 Report, Opens Third Annual cdCon with New Project CDEvents, New Members

    CD Foundation veteran Fatih Degirmenci joins as General Manager

    San Francisco, June 7, 2022 – The Continuous Delivery Foundation (CDF), the open source software foundation that seeks to improve the world’s capacity to deliver software with security and speed, today announced its State of CD Report in 2022, a new project called CDEvents building a vendor-neutral specification for defining the format of event data, new members, and more. The announcement comes at the start of CDF’s third annual cdCon (June 7-8, 2022). cdCon 2022 is being run as a hybrid event from Austin, TX.

    State of CD Report in 2022

    A key function of CDF is providing vendor-neutral data on key DevOps and development metrics showing where continuous delivery stands in 2022 and beyond. The Continuous Delivery Report Series started last year; this is the third report in the series.

    Key findings include:

    • As of Q1 2022, less than a quarter (23%) of developers are not involved in any DevOps-related activities, indicating continued growth in the adoption of practices that increase an organization’s ability to deliver software at high velocity.

    • 47% of developers use either continuous integration or deployment but only one in five use both continuous integration and deployment approaches to automate all building, testing, and deployment of code to production.

    • There is an increase in DevOps adoption in every development sector. Mobile app development has now even leapfrogged desktop development, such is its shift in embracing DevOps approaches.

    The full report is available for free: View the Report (PDF)

    New Project CDEvents Hosted by CD Foundation

    CDF recently announced it is hosting the CDEvents project, a vendor-neutral specification for defining the format of event data to provide interoperability across services, platforms and systems. Today’s CI/CD systems do not talk to each other in a standardized way. Defining a standard set of specifications is critical in solving the interoperability issues across the continuous delivery (CD) ecosystem. Having a common format for events in the CD space will enable an ecosystem of tools to collect, store, visualize and analyze events across CD platforms. This will cover use cases like measuring DevOps metrics and performance and visualizing end-to-end workflows, from the initial development all the way to operations and remediation flows. The current release of the CDEvents specification is available here: https://github.com/cdevents

    cdCon Kicks Off Today in Austin, TX

    cdCon is a two-day virtual event running June 7-8, 2022, focusing on improving the world’s capacity to deliver software with security and speed. This year’s sessions are grouped into 3 channels: Technology Teams, Enterprise Leadership, and Open Source Communities. cdCon is sponsored by IBM, JFrog, Armory, CircleCI, OpsMx, Camunda, Capital One, CloudBees, Cloudsmith, Cloud Native Computing Foundation, Liquibase, Spacelift, and more.

    The full cdCon schedule is available here: https://events.linuxfoundation.org/cdcon/program/schedule/

    “We’re excited to have our first physical event in two years. The pandemic has shown more than ever how important continuous delivery is to industries as they navigate industry and global changes. cdCon generates passionate participation and is a great platform for connecting with peers and understanding best practices,” said Fatih Degirmenci, Continuous Delivery Foundation General Manager. “CDF is committed to providing a clear path for companies to participate in a vendor-neutral structure that can greatly improve organizations’ abilities to deliver software securely and quickly. Come join us at cdCon, there’s still time to register and participate virtually!”

    Keynotes include industry experts and well-known specialists like Isaac Cory Doctorow, Science Fiction Author, Activist, and Journalist; Joe Sepi, Program Director of Open Tech, IBM; Melissa McKay, Developer Advocate, JFrog; Michael Stahnke, Vice President of Platform, CircleCI; Gopal Dommety, CEO, OpsMx; Brian Behlendorf, General Manager, Open Source Security Foundation; Grace Francisco, Vice President, Developer Relations Strategy & Experience, Cisco; Stephen Atwell, Principal Product Manager, Armory; Isaac Mosquera, Principal GTM Leader, Serverless, AWS; and Fatih Degirmenci, Continuous Delivery Foundation General Manager, The Linux Foundation.

    CD Foundation Welcoming New Members

    Cloudsmith, Spacelift, Stackhawk and Tenable are joining the CD Foundation as new members. They join premier members AWS, Armory, CloudBees, Fujitsu, Google Cloud, Huawei, JFrog, Netflix, and Red Hat, as well as the broader open source CI/CD community, in helping to strengthen the growth and evolution of continuous delivery models.

    Cloudsmith – Cloudsmith is a cloud-native, global, universal artifact management platform for engineers looking to set up a secure artifact repository in 60 seconds. Cloudsmith is a Belfast-headquartered startup that has raised $15 million in Series A funding. This is the largest ever Series A funding round in Northern Ireland.

    “We are delighted to join the CD Foundation. How companies deliver software securely and quickly is key to their success, and we believe joining will provide even more value to our customers by connecting us to the broader community of continuous delivery companies and developers around the world,” said Lee Skillen, Co-Founder & CTO, Cloudsmith. “The future of cloud-native software delivery, artifact management and the whole supply chain is critical to industries everywhere, so we are excited to contribute our knowledge of continuous packaging to it.”

    Spacelift – Spacelift focuses on collaborative infrastructure for modern software teams to manage cloud, infrastructure, or services. Its platform uses Terraform, CloudFormation, Pulumi, and Kubernetes offering features such as runtime configuration, version management, and state management. They are backed by Insight Partners, Blossom Capital, Hoxton Ventures and Inovo Venture Partners.

    “We are excited to join the CD Foundation. Spacelift provides a collaboration and automation layer for infrastructure as a code, and we focus on openness, flexibility, and customization. We believe this fits well with the CD Foundation, and by contributing to the direction of open-source CI/CD development through the CD Foundation, our customers will benefit,” said Sean O’Dell, Head of Developer Relations at Spacelift. “By inviting infrastructure, security, compliance, and platform teams to collaborate on and approve workflows and policies, you can improve your infrastructure delivery platform.”

    StackHawk – StackHawk helps developers find and fix application security bugs as part of software delivery. StackHawk makes security part of the developer workflow by running automated security testing in CI/CD and notifying developers immediately about new security issues as they emerge. StackHawk recently announced it has raised $20.7 million as part of a series B funding round.

    “With the rapid pace of software development, security teams are finding it more difficult to test for vulnerabilities on an ongoing basis. At StackHawk, we are placing the ability to resolve vulnerabilities in the hands of the developer, and we see the CD Foundation as a key partner to helping us expand our reach and more broadly address this issue of shifting security left in the development cycle,” said Joni Klippert, co-founder and CEO at StackHawk. “We see the CD Foundation’s ability to guide changes in software development as a strength that will help drive the reduction in security vulnerabilities that make it to deployment.”

    Tenable – Tenable is a cybersecurity company known as the creator of the vulnerability scanning software Nessus. Approximately 40,000 organizations around the globe rely on Tenable to understand and reduce cyber risk. Tenable customers include approximately 60 percent of the Fortune 500, approximately 40 percent of the Global 2000, and large government agencies.

    “As security is a critical component of open source software development and delivery, Tenable will provide expertise and guidance to the CD Foundation,” said Glen Pendley, chief technology officer, Tenable. “The CD Foundation is uniquely positioned to help steer the course of security-focused development in the continuous delivery space. Tenable looks forward to collaborating with this community to enable end users to influence better solutions that drive value for our customers.”

    New General Manager Lead

    CI/CD open source community leader Fatih Degirmenci has joined the CDF as its new General Manager. Fatih is not new to the CD Foundation. He participated in the very first public meeting during the Open Source Leadership Summit in California in March 2019 when the CD Foundation was announced. Since then, he’s been heavily involved in the community including special interest groups (SIG) like the Interoperability SIG and Software Supply Chain SIG. He also served on the Technical Oversight Committee (TOC) as an end-user representative.

    Fatih will work closely with the eight CDF-hosted projects CDEvents, Jenkins, Jenkins X, Ortelius, Shipwright, Screwdriver, Spinnaker, and Tekton, and help members and the wider Continuous Delivery CI/CD community improve their software development security and speed when creating cloud-native, legacy infrastructure, mobile, IoT, and bare-metal applications.

    Additional CDF Resources

    About the Continuous Delivery Foundation

    The Continuous Delivery Foundation (CDF) seeks to improve the world’s capacity to deliver software with security and speed. The CDF is a vendor-neutral organization that is establishing best practices of software delivery automation, propelling education and adoption of CD tools, and facilitating cross-pollination across emerging technologies. The CDF is home to many of the fastest-growing projects for CD, including Jenkins, Jenkins X, Tekton, and Spinnaker. The CDF is part of the Linux Foundation, a nonprofit organization. For more information about the CDF, please visit https://cd.foundation

    The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage Linux is a registered trademark of Linus Torvalds.

    Media Contact
    Jesse Casman, Story Changes Culture
    jesse@storychangesculture.com
    415-730-2793

  • Continuous Delivery Foundation Adds Interoperability Project

    Continuous Delivery Foundation Adds Interoperability Project

    At a CDEventscon event this week, the Continuous Delivery Foundation (CDF) announced it is hosting a CDEvents project through which it hopes to create a vendor-neutral specification for defining the format of event data across multiple services, platforms and systems.

    Andrea Frittoli, open source developer advocate at IBM, co-creator of the CDEvents project and member of the CDF technical oversight committee, said the open source consortium is launching this initiative to foster interoperability across continuous delivery (CD) platforms. In the context of the CDF, that mission spans both continuous integration and continuous deployment platforms that are subsets of CD.

    CDEvents itself is based on an existing CloudEvent specification created by the Serverless Working Group within the Cloud Native Computing Foundation (CNCF). As part of the effort, the CDF has already built a proof-of-concept implementation that enables Tekton pipelines and Keptn orchestration tools for managing application life cycles to communicate over a common event protocol.

    Collecting metrics from multiple DevOps platforms is a challenge because there is no standard for sharing event data. Analytics providers and value stream management platforms that collect metrics need to create connectors for each platform they support. CDEvents would provide a standard interface for collecting metrics from any developer tool or platform. That data would also make it easier to visualize workflows that describe artifacts and their metadata, he added.

    That lack of a common way to describe events means developers not only must constantly re-learn how to consume events, it also limits the potential for libraries, tooling and infrastructure to facilitate the delivery of event data across environments ranging from routers and tracing systems to software development kits (SDKs).

    Naturally, it may be a while before this continuous delivery specification results in increased interoperability across DevOps environments, but the need for one across what has become a patchwork of fragmented tools and platforms is self-evident. Many organizations are already investing in an assortment of analytics tools in the hopes of improving the rate at which applications can be developed and deployed. In too many instances, DevOps teams have inadvertently created bottlenecks that slow down the rate of development. The challenge is that, as new tools and platforms are added to a DevOps workflow, they are not likely to be able to share data with those applications until a connector is created.

    Not everyone, of course, is a fan of having more metrics. The goal should be to coach teams on how to become more efficient rather than implementing a set of draconian mandates. Arguably, such mandates are only going to drive away developers that are trying to strike a balance between coding as an art form and application development as a craft.

    Nevertheless, as organizations better appreciate the critical role software plays in driving business processes, the greater the desire to measure the pace and efficacy of their application development efforts—to justify the levels of investment in software development they are making.

  • Continuous Delivery Challenge Looms Large in 2022

    Continuous Delivery Challenge Looms Large in 2022

    As 2022 kicks off, it’s becoming apparent that the major DevOps challenge organizations will face is mastering best practices that enable continuous delivery.

    A global survey of more than 19,000 software development professionals conducted by the Continuous Delivery (CD) Foundation found 44% of respondents use either continuous integration or deployment. However, less than one in five (18%) use both practices to automate the entire software delivery life cycle. Continuous integration is currently the most popular DevOps-related activity (32%) followed by continuous deployment at 29%, the survey found.

    The survey also found that only 14% of respondents said, on average, that they can go from code checked-in to successfully running that code in production in one day. Just 10% said they routinely deploy code to production each day. Nearly a third of respondents said they still manually approve code deployments to production.

    Tracy Miranda, executive director for the CD Foundation, said it’s clear there is a need for a better understanding of continuous delivery as a distinct DevOps discipline that stands apart from continuous integration processes. While the two DevOps practices are complementary, she noted that continuous delivery requires a level of engineering expertise that many developers either lack or are simply not interested in gaining.

    In fact, the survey found more than a quarter of respondents (26%) are not involved in DevOps-related activities at all. At the same time, however, the survey revealed that 80% of respondents that work for companies with two or more employees are involved in DevOps to some degree. Nearly 60% of enterprise developers that participated in the survey employ a continuous integration/continuous delivery (CI/CD) platform, as opposed to 48% of developers working in small businesses and 42% of contractors. However, it’s clear from the survey results that much of that activity is focused on continuous integration rather than continuous delivery.

    The survey revealed, for example, that less than a quarter of respondents (23%) are involved in infrastructure provisioning and management at all. That compares to nearly a third (32%) that are involved in application and infrastructure monitoring. Only 20% are involved in creating automated tests, Collectively, the survey results make it clear there is still a long way to go in terms of shifting responsibility for DevOps practices further left toward developers.

    One reason continuous delivery is so challenging is that automating deployments across platforms has never been especially easy. Each platform tends to be customized to the point where it is difficult to automate application deployments. In effect, each platform is its own unique type of “snowflake.”

    However, with more attention focused on the integrity of software supply chains in the wake of a series of high-profile breaches, Miranda noted that automating software delivery will play a major role in achieving automation goals by reducing the need to rely on manual processes that are more easily compromised.

    At the same time, more organizations are starting to embrace Kubernetes clusters—this can simplify automation of software delivery across a set of platforms that all share a common application programming interface (API), she noted.

    The growing complexity of application development projects, coupled with increased reliance on software to drive digital business transformation initiatives, will also accelerate the adoption of continuous delivery best practices, added Miranda.

    One way or another, application deployment in 2022 is shaping up to be a lot more automated than it was in previous years. The only thing left to be determined now is the degree to which that goal can be achieved.

  • Report: Lots of Room for Continuous Delivery Improvement

    Report: Lots of Room for Continuous Delivery Improvement

    A report published by the Continuous Delivery (CD) Foundation suggests that, in terms of achieving that goal, most organizations still have a long way to go. Based on analysis of the Developer Nation survey data collected by SlashData, nearly two-thirds of developers said it takes at least one week to go from code committed to code successfully running in production. Only one in 10 developers are deploying code in a production environment multiple times per day.

    On the plus side, half of developers reported that they restore service from an unplanned outage in less than a day.

    The survey identified the top programming languages being employed as shell scripting languages, Go/Golang, JavaScript, PHP, Scala, Dart, C#, Ruby, Python and Java.

    Surprisingly, the vertical industry furthest along in terms of achieving continuous delivery is the retail sector that has embraced digital business transformation, while the furthest behind is the telecommunications sector.

    Tracy Miranda, executive director for the CD Foundation, noted that even after more than 10 years of advocacy, DevOps adoption of CD best practices remains nascent. Many organizations have adopted so-called continuous integration/continuous delivery (CI/CD) platforms, but they are mainly used to drive a set of CI best processes. CD, in comparison, has proven to be a more elusive goal to achieve mainly because each platform on which an application is deployed tends to have unique attributes. Automating the delivery of applications across multiple platforms has, as a result, been difficult to achieve and maintain, she noted.

    Nevertheless, with the arrival of cloud-native container-based applications destined to be deployed on Kubernetes clusters that expose a consistent set of application programming interfaces (APIs), the prospects for more widely achieving CD are improving. Each platform that has a Kubernetes cluster running will expose the same API to a CD platform.

    In the short term, however, Miranda noted that many IT professionals are still somewhat intimated by both Kubernetes and CD best practices. Too many organizations still tend to think of CD as a platform to acquire rather than a set of processes and skills to be defined and nurtured, she added.

    One way or another, however, the CD challenge will need to be addressed as more organizations realize how dependent they are on software to deliver a differentiated customer experience. The rate at which that customer experience improves will determine the level of customer affinity that organizations will be able to attain and retain. That’s doesn’t mean every organization has to be as proficient as, for example, Netflix when it comes to implementing DevOps best practices, Miranda added. However, she said, it’s already apparent most organizations will need to improve how they deliver software to drive multiple digital business transformation initiatives. The opportunity lies in reviewing those processes now with an eye toward creating a culture squarely focused on continually improving the customer experience, she said.

    It may still be a while before most organizations truly master CD, but, as is the case with most journeys, the most important thing is to simply take that first big step.

  • The State of Continuous Delivery in 2021

    The State of Continuous Delivery in 2021

    One of the hallmarks of DevOps is to improve the delivery of software. Therefore, mature DevOps systems employ continuous delivery (CD), the process of releasing bite-sized software changes on a regular basis. Amid high demand for digital innovation, streamlining this release pipeline is becoming more and more crucial for enabling overall software fluidity.

    So, what is the state of CD among today’s development teams? The Continuous Delivery Foundation (CDF) recently released its 2021 State of Continuous Delivery Report, a study that helps establish baseline continuous delivery metrics. Below, we’ll review some key takeaways from the report and discover mean rates for things like deployment frequencies, recovery times and average lead time for code changes.

    Benefits of Continuous Delivery (CD)

    Before we look at the broad metrics surrounding CD adoption, let’s consider: what are the benefits of CD? A big net benefit of CD, the report noted, is that it helps realize feedback earlier in the software development cycle. A lean, CD-driven development approach could help quickly discover features that won’t succeed, which avoids wasting precious development resources.

    CD also increases overall delivery speed for small software chunks. In an era where microservices architecture is all the rage, this process is a necessity for continually initiating many disparate updates. For example, Netflix utilizes Spinnaker to deliver hundreds of microservices and thousands of daily deployments.

    With these results, organizations can reap increased responsiveness and agility. CD can enable fast feedback to changes, which can help businesses adapt to unforeseen conditions, such as zero-day exploits. An investment in CD can also bring net positives to developer team dynamics, according to the report.

    Continuous Delivery Statistics

    Software performance can be indicative of overall organizational performance. So, how should an organization measure its software delivery success? Well, the book Accelerate outlines four crucial metrics to watch: lead time for changes, deployment frequency, time to restore service and change failure rate. The CDF report establishes current industry averages for three of them.

    In terms of deployment frequency, the study found that the highest percentage of developers (31.3%) release once per week to once per month. A large percentage of developers, 27.3%, release every month to six months. Only 10.8% of developers are elite performers, releasing multiple times per day. This indicates that rapid release cycles are still maturing across organizations.

    The average lead time for changes is more variable than you might think. It takes 28.3% of developers one week to one month to go from committed code to running code successfully in production. For 27.3% of developers, this lead time is increased, from one month to six months. Only 5.74% of developers say it takes less than an hour, indicating that a truly on-demand delivery mechanism remains out of reach at most organizations.

    On the other hand, developers are much quicker to act when it comes to restoring services. The survey showed 34.4% of respondents said it takes them one hour to one day to respond to an unplanned outage. A significant number, 15%, respond to incidents in less than one hour. Still, about 50% of outliers are responding somewhere between one day and more than six months.

    Decreasing the mean time to recovery (MTTR) is imperative to respond to broken applications, quickly address security vulnerabilities, and meet evolving customer expectations. As a result, MTTR has become a de facto metric for Site Reliability Engineers (SREs) to watch closely.

    Factors That Affect Software Delivery

    Other factors may influence software delivery agility, such as industry type and programming language preferences. Out of the many industries attempting to refine their delivery models, the report highlighted retail as an industry that ranks high in both speed and stability metrics. Other sectors, such as financial services, government and energy ranked high on stability yet received only average scores for speed. Industries like telecommunications received poorer overall scores.

    Programming language choices may also dictate overall software delivery performance. The study found that shell scripting languages, Go, JavaScript, PHP and Scala were among the top five programming languages, based on the combined software delivery performance data for organizations using each language.

    DevOps Aims to Improve CD

    Continuous delivery is vital to responding quickly to changes and enabling iterative, progressive delivery of new features.

    Another facet of modern CD that can’t be understated is the widespread prevalence and reliance on open source tools. CDF open source packages like Jenkins, Jenkins X, Spinnaker and Ortelius remain vital to enabling CD processes for numerous developer teams.

    The 2021 State of Continuous Delivery Report provides a baseline of standard continuous delivery practices across companies and sectors. The findings are based on SlashData’s Developer Nation survey, which reached 19,000+ respondents from 155 countries from late 2020 to early 2021. One area where reporting is lacking is change failure rates, which we hope future studies will benchmark. For more insights, you can download the report here.

  • Armory Offers Framework to Extend Spinnaker

    Armory Offers Framework to Extend Spinnaker

    Armory, provider of a curated instance of open source Spinnaker continuous delivery (CD) software, is making generally available an open source plugin framework for any instance of Spinnaker.

    Announced this week at its online OPEN CORE SUMMIT, the framework has already been employed to create 15 plugins for Spinnaker, including an observability tool from Armory and a provisioning tool from Pulumi. The plugin framework creates extension points that provide standardized interfaces for creating plugins that invoke various microservice within the Spinnaker CD platform.

    Armory CTO Isaac Mosquera said the goal is to make a Spinnaker platform now being developed under the auspices of the Continuous Delivery (CD) Foundation more easily extensible. The relationship between the frameworks and Spinnaker is naturally symbiotic; more extensions are needed to increase the appeal of the platform. Organizations are unlikely to build those extensions unless Spinnaker achieves a critical mass of adoption.

    Originally developed by Netflix, Spinnaker is being advanced by CD Foundation, along with the Jenkins and Jenkins X continuous integration/continuous delivery (CI/CD) platforms. Organizations will employ different platforms under different circumstances, but the Spinnaker platform does enjoy the capability of being integrated with multiple CI platforms that DevOps teams already have in place, noted Mosquera.

    That ability to mix and match DevOps platforms is becoming more critical as IT environments become more hybrid, he said. The expectation is support for Tekton pipelines, which were originally developed by Google and now are part of the CD Foundation portfolio, will be added to various CI/CD platforms to make it easier to integrate DevOps pipelines.

    In the meantime, a debate surrounding how to implement best GitOps practices is starting to swirl. Thanks to the rise of Kubernetes, it is becoming easier to employ GitOps processes to automate the pulling of code from a Git repository onto any platform. In some cases, that approach might reduce or eliminate the need to rely on a dedicated CI/CD platform to manage that process. Conversely, Mosquera noted CD platforms such as Spinnaker also provide a range of capabilities that span everything from automating audit process to rolling back application code in event of a major deployment issue.

    In the meantime, the amount of code moving through DevOps pipelines continues to increase. Simultaneously, the code is arriving in form of microservices that, although are comparatively easier to build, are often more challenging to deploy, update and manage.

    It’s not clear how many organizations might be looking to replace existing DevOps platforms to manage those processes more effectively. However, more organizations are embracing DevOps processes more widely to deal with an ever-increasing volume of code. As such, the number of organizations adopting open source DevOps platforms in one form or another will continue to rise. Most of those organizations, however, are unlikely to want to download on their own the raw bits that make up those projects.