devopsy.kinsta.cloud

Tag: circleCI

  • AI Coding Agents Are Pulling CI Feedback Into the Inner Loop

    AI Coding Agents Are Pulling CI Feedback Into the Inner Loop

    The traditional shape of CI/CD assumed humans worked in the inner loop and pipelines policed the outer one. AI coding agents are tearing that geometry apart. When code can be generated in seconds, waiting until a pull request to run validation, tests, code review and standards checks turns the outer loop into a backlog of preventable rework. The pipeline itself becomes the bottleneck — and the bottleneck shows up not just as time lost but as wasted tokens, half-finished features and engineering controls that fall behind the rate of change.

    Rob Zuber, CTO of CircleCI, joined Mike Vizard to lay out how that pressure is reshaping CI/CD platform design. Zuber’s read is that CI quality work has to live where the work is actually happening — inside the developer and agent loop — so issues are surfaced and corrected before changes ever leave a working branch. That means pushing validation, testing, agentic review and deterministic guardrails right up against the moment code is generated, rather than catching problems hours or days later in a pipeline run.

    Zuber and Vizard dig into what shifting that feedback earlier actually requires under the hood. Agentic review needs deterministic checks it can trust, observability has to extend to agent behavior, and feature flags become a far more central tool when changes are landing at machine speed. DORA metrics still matter, but Zuber argues the leaders are layering token consumption and pipeline efficiency on top to see whether AI is actually compounding throughput or just compounding cost.

    The bigger shift is one of control surface. As AI amplifies how much software an organization can produce, the engineering controls around quality, security and release safety have to amplify in lockstep — or the gains evaporate.

  • CircleCI Adds Release Orchestration Capability to CI/CD Platform

    CircleCI Adds Release Orchestration Capability to CI/CD Platform

    CircleCI today added a release orchestration capability to its namesake continuous integration/ continuous delivery (CI/CD) platform to give developers more control over application deployments.

    CircleCI CTO Rob Zuber said a CircleCI releases capability provides development teams with the ability to release a controlled subset of their code in a live production environment in a way that provides immediate feedback on how that code is performing. That level of visibility can then be used to determine whether that code might need to be rolled back using automation tools embedded in the CircleCI CI/CD platform, he added.

    In the absence of that capability, noted Zuber, it takes DevOps teams, on average, 45 minutes to an hour to manually roll back an application.

    Initial platforms supported by CircleCI releases are Kubernetes and Amazon SageMaker. CircleCI releases is also compatible with the open source Argo CD platform that CircleCI integrated its platform with last year.

    CircleCI also plans to add support for blue-green deployments later this year, enabling DevOps teams to deploy one application version more gradually to replace another.

    The way CD is managed often varies widely from one organization to another. In highly regulated industries, CD is typically managed by a central team to ensure compliance requirements are met. In other instances, developers are directly responsible for building and deploying their code. Regardless of approach, CircleCI enables organizations to define a set of guardrails to ensure best practices are observed, noted Zuber. In effect, each organization can implement a set of checks and balances that are aligned to their specific needs, he added.

    As DevOps continues to evolve, more organizations want the ability to control deployments at a more granular level by, for example, only making a new application or an update available to a select number of users. Once deployed, developers need a more holistic view into not just how that application is performing but also how it impacted the business, said Zuber. If, for example, the number of logins declines after an update, a developer needs the information to determine whether that update should be rolled back as quickly as possible, he added.

    It’s not clear how many organizations are managing the entire CI/CD workflow on an end-to-end basis. While most DevOps teams make extensive use of CI to build an application, the deployment of applications is still often managed manually. However, as CD capabilities become simpler to employ across platforms with standard interfaces, the number of organizations automating CD should steadily increase. In fact, that capability will soon prove essential as, thanks to the rise of generative artificial intelligence (AI), the pace at which applications are being built only continues to accelerate.

    In the meantime, each organization will need to determine how closely it wishes to integrate CI and CD workflows. However, the more tightly integrated these processes become, the simpler it becomes for developers to assume full responsibility for building and maintaining the software they create.

  • CircleCI Extends CI/CD Reach to AI Models

    CircleCI this week revealed it is extending the reach of its continuous integration/continuous delivery (CI/CD) platform to make it simpler to incorporate artificial intelligence (AI) models into DevOps workflows.

    In addition to providing access to the latest generation of graphical processor units (GPUs) from NVIDIA via the Amazon Web Services (AWS) cloud, Circle CI has added inbound webhooks to access AI model curation services from providers such as Hugging Face and integrations with LangSmith, a debugging tool for generative AI applications and the Amazon SageMaker service for building AI applications.

    CircleCI CEO Jim Rose said while there is clearly a lot of enthusiasm for incorporating AI models into applications, the processes being used are still immature, especially in terms of automating workflows that include testing of probabilistic AI models.

    Most AI models are built by small teams of data scientists that create a software artifact that needs to be integrated within a DevOps workflow just like any other artifact, noted Rose. The challenge is that most data science teams have not yet defined a set of workflows for automating the delivery of those artifacts as part of a larger DevOps workflow, he added.

    DevOps teams will also need to make adjustments to a version control-centric approach to managing applications to trigger pipelines to pull AI software artifacts that exist outside of traditional software repositories. For example, the inbound webhooks provided by CircleCI now make it possible to automatically create a pipeline whenever an AI model residing on Hugging Face changes.

    It’s still early days as far as the deployment of AI models in production environments is concerned, but there is no doubt generative AI will have a major impact on how software is developed. AI models are a different class of software artifacts that are retrained instead of being updated, a process that occurs intermittently. As such, DevOps teams need to keep track of each time an AI model is being retrained to ensure applications are updated.

    At the same time, generative AI will also increase the pace at which other software artifacts are being created and deployed. Many of the manual tasks that today slow down the rate at which applications are built and deployed will be eliminated. That doesn’t mean there will be no need for software engineers, but it does mean the role they play in developing and deploying software is about to rapidly evolve. DevOps teams need to evaluate both how generative AI will impact the tasks they manage as well as the way the overall software development life cycle (SDLC) process needs to evolve.

    Each organization, as always, will need to decide for itself how best to achieve those goals depending on the use cases for AI,  but the changes that generative AI will bring about are now all but inevitable. The longer it takes to adjust, the harder it will become to overcome the cultural and technical challenges that will be encountered along the way.

  • Stop Leaking Secrets!

    Stop Leaking Secrets!

    Merriam-Webster defines a secret as something kept from others or shared only confidentially with a few. Modern software development teams use software secrets such as passwords, tokens and API keys to properly set up, protect and maintain development environments and delivery pipelines and to enable programmatic access to services such as AWS Buckets or Azure Blob Storage for cloud-native apps. Yet, while secrets are critical for modern software to function, they are difficult to manage across delivery stages. All too often, software teams trip over the complexities and inadvertently leave these secrets exposed in both public and private software repositories.

    Potential exposures can stem from many factors: Plain text passwords, weak cryptography, flawed CI/CD or packaging automation and compromised developer accounts or malicious insiders. Whatever the cause, bad actors are regularly scouring repositories and application binaries for hard-coded secrets they can exploit. Look no further than the CircleCI and CodeCov incidents, where exposed secrets left these organizations vulnerable to adversaries intent on attacking software supply chains.

    Rethink Secrets Prioritization

    According to GitGuardian analysis, 10 million new secrets occurrences were exposed on GitHub in 2022, a 67% increase compared to the company’s 2021 findings. As software becomes larger and more complex–with open source, third-party and commercial components–the number of detected secrets will only increase, creating a different challenge: Prioritization for remediation.

    Regrettably, teams lack a scalable means to understand which detected secrets developers can’t or shouldn’t remediate. Today, teams must manually sift through potentially thousands of detections and understand their context to triage these threats. Gaining context means discovering where secrets reside (in your code, in a software dependency, in the documentation included with your software) and understanding their purpose (to access resources, to enable user testing, to enable intrusion detection).

    As teams consider how to simplify and automate the prioritization of secrets, important questions to consider include:

    ● What secrets are your developers responsible for protecting? For example, secrets used to access internal CI/CD pipeline technologies. Depending on permissions, leaking these secrets enables malicious actors to change automated build processes with no one being the wiser. Similarly, API credentials to access data or services needed for their code to function. Leaking these secrets gives malicious actors programmatic access to those APIs, which can be a gold mine of customer data or further compromise the environment.
    ● What secrets are worth protecting? There are some you may be responsible for but which are not worth protecting. For example, to facilitate automated software testing, developers typically publish API keys and certificates in public repositories alongside their applications or in documentation bundled into release packages or software containers. Since these testing “secrets” are designed to be commonly shared, they should not be encrypted or protected.
    ● Which detected secrets are not actionable? For example, developers typically cannot manage secrets in third-party or commercial components and dependencies within software. Instead, these exposures represent a third-party risk management problem. Another example is canary secrets added to software by security operations; remediating these secrets hampers intrusion detection.

    Once teams have established their secrets definitions, building a process to identify and prioritize them comes next.

    Managing Secrets

    Any organization involved in software development should have clear rules for handling and incorporating secrets into code and for communicating that process and those rules to developers. Here are secrets best practices every organization should take into consideration:

    ● Promote developer best practices — and monitor compliance: Secrets leaks are more likely to occur in development organizations that lack clear guidelines for properly managing secrets in their code and easy-to-use tools to implement those guidelines. DevOps teams should formulate policies based on an understanding of how secrets are generated within their development environment, how those secrets are protected once deployed and how (hopefully) they are eventually cycled out of use.

    ● Revamp how applications use secrets: Design applications in a way that eliminates the reliance on access tokens that reside in code. Use technologies like OAuth OpenID Connect (OIDC) tokens that allow developers to authenticate users without directly exposing user credentials in code. Reduce the risk of abuse by using multi-factor authentication, leveraging identity and access management platforms and setting IP ranges that limit inbound connections for APIs to known addresses or address ranges.

    ● Establish end-to-end security: Misconfigurations in CI/CD tooling or release oversight can result in the inclusion of secrets during final builds that might otherwise escape notice during a code audit. Consider implementing binary analysis to extend visibility into leaked secrets beyond raw code and into software packages and containers ready for release. This capability can detect exposed secrets resulting from build or packaging automation.

    ● Streamline secrets prioritization: Noisy scanning results create a ton of triage work just to weed out false positives (e.g., widely distributed testing keys or network credential placeholders) before remediation can start. Automating some of this triage with relevant file intelligence saves countless hours of effort and ensures developers focus on addressing actual risks.

    No Silver Bullet

    Unfortunately, there is no “silver bullet” fix for software supply chain risks and attacks, nor for leaks and exposures. Instead, organizations need a holistic approach that includes scoping the problem, addressing short-term risks posed by leaked credentials and then extending changes in all processes with an eye toward taking the toil out of identifying, prioritizing and remediating secrets leaks—and therefore preventing potential supply chain attacks before they can happen.

  • CircleCI Report Surfaces DevOps Productivity Gains

    An analysis of more than 14 million workflows from thousands of organizations conducted by CircleCI, a provider of a continuous integration/continuous delivery (CI/CD) platform, revealed the mean-time-to-recovery (MTTR) decreased by about 13% year-over-year.

    Half of CI workflows (50%) recovered from a failed run in 64 minutes or less. That compares to 73 minutes or more in previous years, the report noted.

    In general, the report found 50% of workflows completed in 3.3 minutes or less. However, the average duration was approximately 11 minutes. The median workflow ran 1.54 times per day.

    Success rates, as defined by the number of passing runs divided by the total number of runs, was, on average, 77% for default branches and 67%, on average, for non-default branches.

    Naturally, the level of productivity any given DevOps team can achieve is impacted by everything from the size of the team to the vertical industry they operate in. CircleCI CTO Rob Zuber also noted there are other crucial developer productivity metrics, such as the amount of time developers are focused on writing code, that need to be tracked as well.

    The goal for any DevOps team is to abstract away as much complexity as possible to enable developers to spend more time on writing business logic, said Zuber. Unfortunately, as more responsibility for infrastructure and security has shifted left toward developers, many of them are spending too much time managing application environments instead of writing code, noted Zuber. He noted that the cognitive load being placed on developers today is too high.

    Developing applications is, of course, as much an art as it is a science. Organizations can set aside time for sprints to write code, but it’s difficult to dictate when inspiration might strike a particular developer. There is always going to be a need to let developers, for example, write code at odd hours of the day and night. The more friction they encounter in terms of spinning up application environments, the less likely it becomes a developer will spend time squarely focused on writing code, said Zuber. The “zone” is when most of the best code is developed, he added.

    Naturally, there is no set of metrics that are equally applicable to all DevOps teams, but they should pay attention to metrics as an indicator of whether teams are improving, added Zuber. Most developers and software engineers are not going to want to work in a “software factory” where every minute of the day needs to be accounted for within a project management application. Rather than employing metrics as a stick, they should instead be used as an educational tool—a carrot—that drives steady improvement. In addition, organizations should take care to make sure the collecting of metrics doesn’t impede the pace at which applications are being developed.

    As the saying goes, things measured are usually things done; but there is a fine line to be observed when it comes to any goal that requires a certain level of creativity to achieve.

  • Appdome Integrates Mobile Security Platform With CircleCI CI/CD

    Appdome Integrates Mobile Security Platform With CircleCI CI/CD

    Appdome this week made available an integration for the continuous integration/continuous delivery (CI/CD) platform from CircleCI that promises to make it simpler to secure mobile applications before they are deployed.

    As a provider of a platform for securing mobile applications running on iOS and Android platforms, Appdome provides a runtime application self-protection (RASP) platform that, among other capabilities, provides code obfuscation, mobile data encryption, jailbreak detection, root detection, man-in-the-middle attack prevention, on-device anti-malware, anti-fraud, anti-cheat and anti-bot capabilities.

    The platform is now integrated with the Circle CI/CD platform via the Orb framework created by CircleCI to simplify integrations with third-party tools.

    Karen Hsu, senior vice president of mobile DevOps and security solutions for Appdome, said the Appdome Build_2Secure Orb for CircleCI is an example of a series of integrations the company plans to make involving DevOps tools and platform that will make it easier to apply DevSecOps best practices to the deployment of mobile applications. That’s critical because it’s not uncommon for teams using different DevOps platforms and tools to be involved in the development of the same application, she noted.

    A recent Appdome survey suggested consumers are about to force the DevSecOps issue for providers of mobile applications regardless of how mature their processes are. A full 94% of respondents said they would promote a brand if the mobile apps protected them versus 68% that said they’d abandon brands that offered no protection.

    Securing mobile applications is especially challenging because once an application is compromised, it’s relatively trivial for cybercriminals to also inject malicious code into other applications running on a mobile device. There are no automated remediation capabilities, so the best defense is to isolate applications in a way that prevents malware from executing in the first place, noted Hsu. At a time when it’s already clear cybercriminals will be using artificial intelligence (AI) platforms to launch attacks, organizations will not have the time required to remediate vulnerabilities before malware is activated, she added.

    That Appdome approach provides the added benefit of reducing tensions between developers and cybersecurity teams that otherwise would be requesting immediate fixes to mobile applications that have been compromised, noted Hsu. As more mobile applications are built and deployed, the overall goal should be to enable both teams to work collaboratively together without unnecessarily disrupting each other’s workflow, added Hsu.

    It’s not clear what percentage of the applications being built and deployed today are destined to run on mobile devices, but securing those applications clearly presents some unique challenges. Many of those applications are deployed on consumer-grade devices attached to wireless networks that are not especially secure. Cybercriminals are increasingly targeting these devices not only to access sensitive data but also because they often provide a gateway through which the rest of an IT environment can be compromised.

    The simple truth of the matter is, sadly, DevOps teams need to assume that most mobile applications are going to be running in the cybersecurity equivalent of a hostile environment where the odds are considerably stacked against them.

  • New Relic Extends Observability Reach to More DevOps Platforms

    New Relic Extends Observability Reach to More DevOps Platforms

    New Relic today expanded its ecosystem by adding integrations between its observability platform and a wide variety of DevOps and cybersecurity tools. The New Relic observability platform now integrates with offerings from Atlassian, Amazon Web Services (AWS), CircleCI, Confluent, GitHub, JFrog, Lacework and Snyk and the open source Jenkins continuous integration/continuous delivery (CI/CD) platform.

    Peter Pezaris, senior vice president for strategy and experience at New Relic, said the goal is to make it simple to share analytics based on telemetry data collected from IT operations environments with the tools organizations rely on to build and deploy applications.

    In total, there are now more than 500 integrations with the New Relic observability platform, he noted.

    Only 27% of respondents to a recent New Relic survey reported that they have achieved full-stack observability and only 5% claimed they have a mature observability practice in place. A third (33%) of respondents also said they still primarily detect outages manually or based on complaints from end users. More than half (52%) of respondents said they experienced high-business-impact outages once per week or more and 29% said they take more than an hour to resolve those outages.

    On the plus side, nearly three-quarters (72%) of respondents expected to maintain or increase their observability budgets next year, with more than half (52%) expecting observability budgets to increase over the next year.

    Observability, in one form or another, has always been a tenet of any DevOps practice. For the most part, the best that could be achieved until recently was continuous monitoring of a set of pre-defined metrics. With the arrival of observability platforms, it’s becoming much simpler to not only monitor metrics but also launch queries that surface issues long before an IT service can be disrupted.

    An observability platform achieves that goal by making it possible to query logs, metrics and distributed traces in a way that surfaces patterns that have not been pre-defined. In effect, an observability platform makes it simpler to debug application environments where the number of dependencies that exist between services are becoming too complex to track or decipher manually.

    Of course, those applications will need to be instrumented using agent software capable of generating the data observability platforms require. Fortunately, open source projects such as OpenTelemetry are helping to drive down the total cost of instrumentation by making agent software more accessible to a wider range of application developers.

    It’s not clear how quickly IT teams will be embracing observability platforms, but there is now a clear opportunity to narrow the divide between IT operations teams and application developers, noted Pezaris. As each DevOps platform makes it easier to collect data via application programming interfaces (APIs), richer telemetry data can be collected, he added.

    In the meantime, as application environments continue to become more complex in the cloud-native era, most DevOps teams will need additional tools. Existing legacy monitoring tools don’t make it easy to discover, for example, which microservice might be adversely impacting the overall performance of an application because calls are being rerouted. The frustrating thing, as always, is that it can take days or weeks to pinpoint an issue that might take only a few minutes to fix.

  • CircleCI Will Use AI to Increase Collective DevOps Intelligence

    CircleCI Will Use AI to Increase Collective DevOps Intelligence

    CircleCI has committed to adding additional collective intelligence capabilities to its continuous integration/continuous delivery (CI/CD) platform that will leverage machine learning and other forms of artificial intelligence (AI) to optimize application development and delivery.

    CircleCI CEO Jim Rose said that as the company’s namesake CI/CD platform continues to collect more telemetry data from multiple customers, it becomes feasible to create AI models that will optimize everything from application testing to reliability and performance.

    As part of that strategy, CircleCI has also added capabilities such as test splitting recommendations that employ machine learning algorithms to estimate the expected time savings of enabling parallelism on test jobs.

    In addition, CircleCI is creating a team of analysts and data scientists to develop additional AI capabilities based on the data collected via the cloud version of the company’s platform.

    The decision to invest more in developing AI capabilities follows the acquisition of Ponicode, a provider of a unit testing platform, earlier this year. That platform uses AI to augment application testers by providing capabilities such as syntax validation, on-hover hints and autocompletion capabilities to improve the accuracy of software developed using Visual Studio Code. The goal is to integrate that AI testing technology within the CircleCI platform to make it possible to apply algorithms to individual developers’ code as well as to code aggregated from multiple developers within a build as it is continuously updated across a DevOps workflow.

    The workflows make up a software supply chain that, in many regards, functions like any other type of supply chain, noted Rose. As such, there is plenty of opportunity to apply AI models to optimize those workflows in the same way AI is being applied to optimize other types of supply chains, he added.

    It’s still early days as far as applying AI to DevOps processes is concerned, but it’s clear there is a need to further automate a wide range of manual processes. It’s not likely that AI is going to replace the need for DevOps engineers any time soon, but it will reduce a lot of the toil that currently hinders productivity. The challenge, of course, is that it takes a lot of telemetry data to train an AI model, which typically can only be efficiently gathered and stored with a cloud platform. Less clear is whether AI capabilities might drive more organizations to shift away from legacy CI/CD platforms deployed in an on-premises IT environment where there might not be enough telemetry data available to effectively train an AI model.

    The one thing that is certain is there is now a race to apply AI to DevOps workflows. Organizations that have adopted DevOps typically are highly committed to automation, but the amount of AI applied to those workflows has been limited thus far. In the coming year, however, chances are good the amount of AI being applied to DevOps workflows will steadily increase, especially as many DevOps teams struggle to keep pace with complex application environments.

  • CircleCI Integrates CI/CD Platform With GitLab

    CircleCI Integrates CI/CD Platform With GitLab

    CircleCI today announced it has integrated its continuous integration/continuous delivery (CI/CD) platform with a rival software-as-a-service (SaaS) offering from GitLab.

    DevOps teams can now, for example, trigger pipelines in CircleCI from GitLab forked merge requests in addition to merging requests and making commits for specific branches. Other capabilities include the ability to access testing capabilities on the CircleCI platform and integrate permissions to ensure security.

    CircleCI CEO Jim Rose said the company routinely integrates its CI/CD platform with other offerings because organizations typically have multiple teams using different version control platforms at different times. The goal is to give those teams access to capabilities and best practices regardless of which specific platform they are using.

    In general, Rose said organizations are trying to strike a balance between the standardization of DevOps platforms and the need to enable development teams to innovate by adding new tools. Standardization tends to create more opportunities to automate more tasks in ways that reduce costs. However, developers will eventually rebel against any effort to limit the choice of tools they use to improve productivity, noted Rose. Too many senior IT leaders are quick to assume that a plethora of tools is an indication of a problem rather than the result of ongoing experimentation, he added.

    In the wake of the global economic downturn, many organizations are also revisiting their existing DevOps workflows to try to increase overall efficiency by automating more tasks. Those organizations realize they can’t afford to continue throwing labor at manual DevOps tasks, Rose added.

    The challenge, of course, is that building and deploying modern software is becoming more complex. Organizations are embracing microservices to make applications more resilient as they realize how dependent they are on software. The issue is that as the number of microservices continues to expand, it becomes apparent that legacy manual processes will not scale, said Rose. As a result, the impetus to automate DevOps processes becomes that much greater, he added. Less clear is to what degree organizations that have already embraced DevOps platforms might be willing to swap out their current CI/CD platform to achieve that goal.

    In the meantime, more organizations are embracing DevOps to manage software development projects that drive a wide range of digital business transformation initiatives. The applications driving those processes typically need to be continuously updated as business requirements change. That becomes much easier to achieve when using processes optimized around continuous development and deployment.

    Regardless of which underlying CI/CD platform organizations choose, they should assume that, eventually, some level of integration between those platforms will be necessary. After all, in the event of an acquisition, for example, it’s not likely both companies will have standardized on the same DevOps platform. Given the amount of time required to migrate from one DevOps platform to another the amount of time required for interoperability is inevitably going to be measured in months if not years.

  • CircleCI Report: Pipeline Optimization Best Practices

    CircleCI Report: Pipeline Optimization Best Practices

    CircleCI today published a report that found most successful software engineering teams have average workflow durations of five to 10 minutes, with any failed run being fixed or reverted in under an hour.

    The report was based on two years of data gathered from more than a quarter-billion workflows and collected from nearly 50,000 organizations using its continuous integration/continuous delivery (CI/CD) platform. The CircleCI 2022 State of Software Delivery Report also found those teams have success rates that are above 90% for the default branch of their application and deploy at least more than once per day.

    Mike Stahnke, vice president of platform for CircleCI, said the report also makes it clear there is no correlation between team size and the level of DevOps success achieved.

    Organizations that focus on optimizing pipelines are also better able to integrate testing within their DevOps workflows, he noted.

    In general, Stahnke said more DevOps teams are relying on cloud-based CI/CD platforms versus opting to deploy and maintain infrastructure themselves. That shift also lowers the barrier to entry for organizations looking to embrace DevOps best practices to accelerate application development, he added.

    Less clear is the degree to which organizations have embraced both CD and CI. While many developers routinely employ CI to accelerate application development, CD has proven to be a more elusive goal. Each platform a DevOps team supports tends to have unique attributes that require them to rely on manual processes to deploy applications. However, as DevOps processes continue to mature, Stahnke said the CI and CD integration will become more seamless. In fact, as the number of applications that organizations build simultaneously increases, the pressure to automate CD will also rise.

    However, it remains to be seen to what percentage of organizations will opt for a tightly integrated CI/CD platform versus separate CI platforms for developers and CD platforms for IT operations teams that are more loosely coupled.

    In the meantime, organizations of all sizes are clearly more focused than ever on developer productivity. In the wake of the downturn brought on by the COVID-19 pandemic, there was a rush to launch a range of digital business transformation initiatives. The issue that many organizations are now encountering is they need to find ways to enable a finite number of developers to simultaneously build and deploy multiple applications with multiple interdependencies. Many organizations are trying to address that challenge by sharing best practices across DevOps teams that have varying levels of maturity. Few organizations have a set of standardized DevOps practices that are consistently employed across every application development team within an enterprise.

    It will be up to each organization to decide whether to compare their level of DevOps expertise to other organizations. Each application development team faces a unique set of challenges. The most important goal is simply to continuously improve at a time when demand for custom applications has never been greater.