devopsy.kinsta.cloud

Tag: cloudbees

AI, the New Hero of Software Development … or Anti-Hero?
Artificial intelligence (AI) can be a hero or an anti-hero in software development, depending on your implementation approach. According to the 2024 DORA Accelerate State of DevOps Report, AI adoption shows promise with 75% of respondents reporting positive productivity gains, but also reveals unexpected challenges, including a 7.2% reduction in software delivery stability.

The key is to position AI as a supportive partner. AI should be utilized to enhance human expertise rather than replace it.

AI Is Promising, but Let’s Stay Suspicious

AI has been rapidly infiltrating software development for almost two years now. Coding assistants, automated testing tools, and AI-powered analytics promise to transform how we build applications, and some early adopters have shown impressive results. When AI first entered development workflows, it tackled well-defined problems such as code completion, simple test generation, commenting, and draft documentation with reasonable success.

But that initial enthusiasm has given way to more complex realities. Modern software development involves intricate systems, multi-cloud deployments, complex security requirements, and accelerating delivery expectations. AI has shown both remarkable capabilities and concerning limitations in this environment.

After hearing customer stories about dozens of AI implementations, I’ve found the story isn’t as binary as “hero” versus “villain”—it’s more like “hero” versus “erratically-troubled-if-ultimately-victorious anti-hero.” The reality of AI is nuanced—and much more interesting, depending very much on the implementation approach, governance scheme, and where organizations choose to apply AI technologies.

The Toil Problem Is Real and Measurable

Every developer knows the frustration of “toil”—those manual, repetitive tasks that consume time without adding much value. Toil isn’t just a minor annoyance. The 2024 DORA report confirms that this challenge remains persistent, with developers continuing to struggle with time allocation between valuable work and repetitive tasks.

Recently, I had the chance to discuss AI heroism and anti-heroism with the Chief Product Officer of CloudBees, Shawn Ahmed. CloudBees is an enterprise DevOps solutions provider and was co-founded by Jenkins creator Kohsuke Kawaguchi, so it has been in a good position to observe the thousand ways AI has been injected into software development. Their internal research indicates developers spend about half of their time triaging test failures, waiting on build times or addressing security issues—and as little as 20–30% of their time writing code. As Ahmed pointed out to me, this inefficiency seems like it wouldn’t be tolerated in most other industries; it is like accepting a manufacturing line that’s only 20–30% effective.

An example of CloudBees’ approach to incorporating AI productively and helpfully is their continuous integration (CI) capability. It analyzes historical pipeline data to identify patterns in successful deployments and uses AI to provide suggestions for future deployments. This eliminates hours of configuration work, thanks to AI’s ability to base pattern recognition on thousands, if not millions, of data points.

From CloudBees’ perspective, AI in software development isn’t a replacement technology in dev but rather what Ahmed characterizes as a “companion.” AI’s best role is handling routine tasks to preserve and expand the human developer’s time performing creative and strategic work.

Three Implementation Models, Three Different Outcomes

It’s clear that not all AI implementations are created equal. I see three distinct approaches emerging, each with dramatically different results:
1. The Replacers: Some organizations approach AI to reduce headcount by automating development tasks. This model typically delivers poor results, fundamentally misunderstanding both AI capabilities and the creative nature of software development. The DORA research supports this concern, showing that while AI adoption is widespread, 39.2% of respondents reported having little or no trust in AI-generated code, indicating that successful implementations require human oversight.
2. Tools First!: These organizations adopt individual AI tools without a cohesive strategy or governance framework. This approach delivers mixed results—productivity improves in specific areas, but in many cases at the cost of quality, security, or long-term maintainability. The DORA findings highlight this challenge, showing that despite AI’s positive impact on individual productivity and code quality, it can lead to decreased software delivery performance.
3. The Augmenters: The most successful approach treats AI as an amplifier of human capabilities rather than a replacement. The DORA research validates this model, showing that AI adoption leads to meaningful improvements: when AI adoption increases by 25%, individual productivity increases by 2.1%, flow improves by 2.6%, and job satisfaction rises by 2.2%.
CloudBees is built on this augmentation philosophy. According to Ahmed, AI handles pattern recognition and repetitive tasks while humans make decisions on strategic matters. Their DevSecOps solution demonstrates this approach by using AI to identify security vulnerabilities while preserving human authority over remediation strategies. CloudBees’ Value Stream Analytics uses AI to spot workflow inefficiencies while leaving process improvement decisions to the teams who understand the organizational context.

Making AI the Hero of Your App Dev Story

Here are five critical success factors that determine whether AI becomes a hero or an anti-hero for you:
1. Target high-toil activities first. Successful implementations start with well-defined, repetitive tasks where AI can deliver immediate value. CloudBees’ recommended targets include test generation, pipeline optimization, and code reviews, including areas where AI can significantly reduce manual effort.
2. Establish governance first, deploy AI second. Organizations seeing positive results implement governance frameworks before widespread AI adoption, defining, for example, appropriate use cases, verification requirements, or clear boundaries for AI autonomy.
3. Invest in developer education. Contrary to some narratives, successful AI implementation requires more skilled developers. Top-performing organizations invest in training programs that help developers understand both AI capabilities and limitations.
4. Integrate rather than isolate. Rather than adopting disconnected point solutions, effective organizations implement AI capabilities that integrate throughout their delivery pipeline. CloudBees’ platform takes this approach, connecting AI capabilities from requirements analysis through production monitoring.
5. Measure meaningful outcomes. The most effective implementations have moved beyond measuring code generation metrics. Instead, they focus on quality improvements, security posture enhancements, and business impact indicators that reflect the true value of AI adoption.
AI Is Your Enthusiastic Partner, Not Your Replacement

Successful AI implementations in app dev seem to share the common characteristic of using it as a complementary force instead of as a replacement. AI is adept at the mundane, repetitive tasks that drain motivation and attention among developers and increase their toil. It lets humans focus on innovation, customer experience, and ultimately, business value.

According to Ahmed, CloudBees envisions a future where AI becomes increasingly personalized to individual developers. He predicts that within two years, developers will likely work with multiple AI companions tailored to their specific preferences and working styles. This personalization aspect represents an important evolution beyond today’s more standardized AI tools.

A particularly noteworthy perspective I got from research and vendor discussions is the relationship between AI adoption and team scaling. While some organizations initially approach AI to reduce headcount, the data suggests the opposite effect. As Ahmed noted in our discussion, the more effective approach isn’t using AI to reduce a 10-person team to 5, but rather leveraging AI to assist that 10-person team in achieving what would have previously required 15 people. This is the proactive, business-building “scale up, not down” perspective that can help propel an organization to its goals.

I’ve concluded that today, the hero of software development isn’t AI. Not AI alone, but it is no longer purely human expertise either. The true hero is the partnership between them, working in concert to create outcomes neither could achieve independently.
June 17, 2025
CloudBees Acquires Launchable to Advance Testing Using AI

CloudBees today revealed it has acquired Launchable, a provider of a test automation platform, to enable DevOps teams to improve both application security and software quality. Financial terms of the acquisition are not being disclosed.

Launchable makes extensive use of both machine learning algorithms and generative artificial intelligence (AI) capabilities to streamline testing processes by, for example, providing access to a co-pilot to ensure the right test is run at the right time.
Additionally, if the platform determines a software component is probably going to fail some portion of a test it will alert DevOps teams to that fact rather than wasting time running a series of tests before there is an inevitable failure.

Sacha Labourey, chief strategy officer for CloudBees, said the addition of the Launchable platform provides organizations with testing capabilities augmented by artificial intelligence (AI) that can be easily added to existing DevSecOps workflows.

In general, application testing remains one of the costly bottlenecks with any software development lifecycle (SDLC). AI tools should substantially reduce time spent on unnecessary tests and inefficient workflows because DevOps teams will know which tests matter most.

In addition, they will be able to automatically launch tests whenever a change is made to code as part of a larger DevOps workflow to ensure that tests are not skipped simply because they might take too much time to run. When a test fails, those same AI tools make it easier to surface the root cause of the issue in a way that makes it simpler for developers to address.

Launchable reports that existing customers such as BMW and GoCardless saw a 50% reduction in machine hours, a 90% reduction in test execution times, and a 40% reduction in build times by relying on AI to automate testing workflows.

AI is already accelerating the rate at which code is being written. The challenge now is applying AI to accelerate the pace at which increased amounts of code can move through DevSecOps pipelines. The overall goal is to improve developer productivity by reducing toil that over time increases burnout among both developers and the software engineers that support them, said Labourey.

It may be a while before AI is pervasively employed across every DevOps workflow but organizations that are at the forefront of adoption are seeing productivity gains. It’s not likely AI will replace the need for DevOps teams. After all, the code and suggestions generated by these tools still need to be reviewed by DevOps professionals to prevent the occasional hallucination from being incorporated into a production environment.

However, the one certain thing is thanks to the rise of AI the pace at which applications are being developed and deployed is about to exponentially increase without necessarily having to dramatically increase the size of DevOps teams. The challenge is that if all those applications are not properly tested that increased pace of deployment might just as easily wind up being too much of the proverbial good thing.

August 7, 2024
From Chaos to Clarity: Streamlining DevSecOps in the Digital Era

These days, securing the software development lifecycle from end to end requires organizations to deploy, maintain, and master a cacophonous mix of tools that often do more to create discord rather than bring harmony to DevSecOps processes. The reason for this is simple: Each tool employed to secure a software supply chain independently runs scans and generates alerts that lack context, are often redundant, or flat-out contradict one another.

Developers and the software engineers that support these applications are, of course, expected to correlate the steady streams of alerts and address vulnerabilities to meet security thresholds required to propagate the release to an upstream environment. The reality is that not all of the vulnerabilities flagged as high and critical need fixing, nor is it possible for a team to address all of the vulnerabilities. On average, a development team has the bandwidth to address 10% of its vulnerability backlog in any given month. This makes it imperative to prioritize the vulnerability backlog based on impact rather than severity if we are to give these development teams a ghost of a chance to succeed in improving their security posture.

The constant alert storms also lead to fatigue and introduce a real risk of false negatives. The one that got away!

DevSecOps workflows today are little more than sections of an orchestra playing without a score with the expectation that some methodology to consistently lock down a software supply chain will magically manifest.

What’s obviously missing is an orchestration framework that triggers the security workflow in response to changes within the SDLC. Ideally, it works seamlessly with the CI/CD workflows, but without being dependent on them, creating a symphony capable of providing a better security posture for the organization.

The Trouble With DevSecOps

In cloud-native, microservices-based application development environments, teams could be developing using multiple technologies, each optimized for delivering a certain service. Each technology may require a certain specialized scanning tool—and that’s just code; by the time we add binary, infrastructure pipeline, data and identity to the mix, you end up with a vast array of tooling and a huge set of policies that every change needs to be assessed against.

Yes, you can scan containers on a periodic basis before deploying to production and that might be OK if you are deploying one release per month. However, even then you could argue that by the time the vulnerabilities are picked up, it’s too late and you have already lost the battle on efficiency.

The very reason you went with a microservice-based architecture is so that it’s easy to scale and quick to build and deploy. Ideally, you would want to be releasing features rapidly for your customers. This means a very high degree of change, which in turn means the point-in-time assessment you did will simply not be fit for purpose in terms of protecting your assets. Every commit has the potential of exposing a new risk, which may end up being discovered too late if left to point-in-time assessments.

Instead, if security is orchestrated seamlessly and asynchronously through tool-agnostic interfaces across your CI/CD pipelines, delivering the outcomes required to secure your digital assets from the first commit right through to the production deployments and beyond, you have truly adopted DevOps. In this scenario, every change is assessed in real-time, and its impact is projected across to development, operations, and security with a clear call to action.

This approach also provides a more extensible and scalable framework for organizations as they advance through their journey of DevSecOps adoption.

Summary

No development team deliberately sets out to build and deploy an insecure application. The reason applications with known vulnerabilities are deployed so often is because the cognitive load associated with discovering and remediating them is simply too high. The average developer can only allocate 10% to 20% of their time remediating vulnerabilities. The rest of their time is spent either writing new code or maintaining the application development environment used to write that code. If organizations want more secure applications, they need to find ways to make it easy for developers to correlate, prioritize and contextualize the vulnerabilities as they are being identified. Most of the time when developers are informed a vulnerability has been discovered in their code, they have long since lost context.

Vulnerabilities need to be immediately identified at the time code is written, builds are created, and pull requests are made – and identified in a way that is actionable. Otherwise, that vulnerability is likely to be thrown atop the massive pile of technical debt that developers hope they’ll one day have the time to address.

At this juncture, it’s only a matter of time before governments around the world enact legislation that will hold organizations more accountable for the security of the software they build and deploy. Savvy DevSecOps teams already recognize that existing approaches to managing DevSecOps workflows will need to be revamped to address these requirements. The challenge and the opportunity now is to put in place a scalable security orchestration framework that eliminates friction in DevSecOps workflows and drives efficiency through real time assessments, ensuring that your software is secure by default.

March 25, 2024
The Future of Jenkins in 2024

As software development practices evolve, the tools that support them must also adapt to stay relevant. Jenkins, the venerable automation server used by many DevOps teams, is at such a crossroads as it faces the changing landscape of cloud-native applications and Kubernetes adoption.

This article examines Jenkins’ current utility, particularly its features that have made it a staple in CI/CD practices, and addresses the question of whether it will maintain its relevance in 2024 and beyond.

How Jenkins is Used by DevOps Teams

CI and CD

Jenkins has become an integral part of many DevOps teams due to its CI/CD capabilities. Continuous integration (CI) is a software development practice where developers regularly merge their code changes into a central repository. Continuous delivery (CD) is the practice of delivering the software in short cycles to ensure that it can be reliably released at any time.

Jenkins supports the CI/CD approach in a number of ways. First, it allows developers to automate code integration. This means that whenever code changes are pushed to the repository, Jenkins can automatically build and test the project. Second, Jenkins allows for the continuous delivery of software by automating simple deployment processes (although it lacks full deployment orchestration capabilities).

Build Pipeline Visualization

Another key feature of Jenkins is its build pipeline visualization. This feature allows DevOps teams to visually represent the process of software delivery from code integration to deployment. The pipeline visualization provides a clear and intuitive representation of the software delivery process, making it easier for teams to understand and manage the process.

Build pipeline visualization in Jenkins is customizable, allowing teams to tailor it to their specific needs. For example, it can be customized to show the status of each stage of the delivery process, from code integration to testing to deployment. This allows teams to quickly identify any issues or bottlenecks in the process and address them.

Automated Testing

Automated testing is another area where Jenkins shines. With Jenkins, DevOps teams can automate the process of testing their code by running scripts and integrating with automated testing tools as part of the build process.

Jenkins supports a wide range of testing frameworks and tools, allowing teams to choose the ones that best fit their needs. Moreover, Jenkins can be configured to automatically run tests whenever changes are made to the code. This ensures that any issues or defects in the code are detected early and can be addressed promptly.

Workflow Scripting

Workflow scripting is another key feature of Jenkins in DevOps teams. With Jenkins, teams can script their workflows, automating the process of software delivery. This allows teams to standardize their workflows, ensuring that each delivery process is consistent and predictable.

Jenkins supports the Groovy scripting language for workflow scripting. This means that teams can use the power and flexibility of Groovy to script their workflows. Moreover, Jenkins provides a user-friendly interface for scripting workflows, making the process easy even for those who are not familiar with Groovy.

Current Usage and Adoption Statistics

As of 2023, Jenkins remains a leader in the CI/CD space. With its extensive plugin architecture and large user base, it is used by thousands of organizations worldwide. According to the 2022 DevOps Survey by the Cloud Native Computing Foundation (CNCF), Jenkins was used by over 50% of respondents for automation and CI/CD, maintaining a significant presence in the market.

According to the Jenkins website, there are over 1 million active Jenkins users and more than 200,000 active installations worldwide, with the platform handling 1 million+ jobs per day. It had about 44% of the global market share for CI/CD in 2023.

The growth trajectory of Jenkins, however, has shown signs of plateauing when compared to newer, more cloud-native-focused CI/CD tools. This observation is backed by Google Trends data, reflecting a steady but not sharply increasing interest in Jenkins over recent years.

Despite facing competition from emerging tools designed for cloud-native development, such as GitHub Actions, GitLab CI and CircleCI, Jenkins has responded by evolving its ecosystem. The creation of Jenkins X is a strategic move to cater to Kubernetes users and address some of the criticisms related to cloud-native development. However, as we’ll discuss, Jenkins X has not been readily adopted by the industry as of yet.

Limitations of Jenkins in Cloud-Native Environments

While Jenkins is a powerful tool for DevOps teams, it has serious limitations in cloud-native environments. These limitations stem from the fact that Jenkins was originally designed for traditional, monolithic applications, not for the dynamic and distributed nature of cloud-native applications.

Statefulness

One of the critical limitations of Jenkins in cloud-native environments is its inherent statefulness. Cloud-native architectures typically favor stateless applications, which are easier to scale and manage in dynamic environments like Kubernetes.

Jenkins, however, relies on maintaining state—it stores configuration, build history and user data, making it challenging to scale and manage efficiently in a cloud-native setup. This statefulness requires persistent storage, which complicates deployments in distributed systems where resiliency and horizontal scaling are key. Moreover, the risk of data loss or inconsistency increases in cloud-native environments, particularly during scaling operations or when recovering from failures.

Configuration Complexity

Jenkins is often criticized for its complex configuration requirements. Setting up Jenkins in a cloud environment involves intricate configurations that are not only time-consuming but also prone to errors. This complexity is exacerbated when integrating with modern cloud-native tools and services, requiring extensive customization and maintenance of plugins.

In addition, Jenkins’ traditional master-slave architecture was not designed for dynamic cloud environments, where resources need to be provisioned and deprovisioned rapidly. This leads to a significant operational overhead for DevOps teams.

Immutable Infrastructure

Adopting an immutable infrastructure approach is a cornerstone of cloud-native environments, promoting the idea of replacing or rebuilding servers rather than modifying them.

However, Jenkins’ traditional model does not align well with this principle. It typically requires modifications to its runtime environment for updates or changes, contrasting with the cloud-native approach of immutable deployments. This can make it challenging to maintain consistency and reliability in cloud-native systems where automation and minimal manual intervention are paramount.

Microservices Limitations

Jenkins was originally designed for monolithic architectures and doesn’t naturally fit into microservice-based applications, which are prevalent in cloud-native environments. In microservices architectures, applications are broken down into smaller, independently deployable services.

Jenkins, however, tends to treat applications as monolithic units, making it less efficient for handling multiple, independent microservices. This limitation affects its ability to provide fine-grained control over individual services’ build, test and deployment processes. Consequently, Jenkins may struggle with the high degree of automation, flexibility and scalability required in microservices environments.

What is Jenkins X?

Jenkins X is an open source project that provides pipeline automation, built-in GitOps, and preview environments to help teams collaborate and accelerate their software delivery at any scale. It is an improved version of the original project, designed specifically for Kubernetes, a popular container orchestration platform.

Jenkins X streamlines the technical aspects of building, testing, and deploying software. It automates the installation of popular tools like Helm and Draft, making it easier for developers to get started. It also provides pre-configured pipelines so teams can start delivering software right out of the box.

Jenkins X also introduces a new Jenkinsfile format, Jenkinsfile.yaml, which provides a more straightforward and human-readable way to describe pipelines. This new format, combined with the automation provided by Jenkins X, helps reduce the complexity of pipeline configuration and management in Kubernetes.

Limitations and Criticisms

Jenkins X has not been widely adopted by the software industry and has not achieved the respect and prominence of its predecessor, Jenkins. Let’s review the main limitations and criticisms of the tool.

Lack of Maturity

Jenkins X’s relatively recent entry into the market means it has not had the time to mature like its predecessor. This lack of maturity can manifest in several ways, including fewer features compared to established tools, fewer community-tested plugins, and potentially more bugs or unresolved issues. Due to the fast-paced evolution of cloud-native technologies, tools need time to adapt and stabilize; Jenkins X is still in this phase of its lifecycle.

Moreover, a mature tool typically has extensive documentation and a large community of users who can offer support and share best practices. While Jenkins X has seen growth in its user base, it still lags behind more mature CI/CD solutions in these areas. This can lead to challenges when teams are looking to solve complex problems or when they require advanced support.

Limited to Git Projects

Another criticism of Jenkins X is that it’s limited to Git projects. While Git is the most popular version control system, it’s not the only one. Some teams may use other systems like Mercurial or SVN, and these teams would be unable to use Jenkins X.

Even within the world of Git, Jenkins X has limitations. For example, it doesn’t support all Git hosting platforms. While it works with popular platforms like GitHub and Bitbucket, it doesn’t support others like GitLab. This can be a significant limitation for teams that use unsupported platforms.

Community Support

Finally, there are concerns about community support for Jenkins X. While the project is open source and theoretically has the potential for wide community involvement, some critics argue that it’s primary source of support is CloudBees, the company behind Jenkins.

These critics worry that if CloudBees were to withdraw its support, the project could falter. They also argue that the project’s focus on certain tools and platforms (like Kubernetes and Git) reflects CloudBees’ business interests more than the needs of the broader DevOps community.

Conclusion

In conclusion, Jenkins’ role in the CI/CD landscape has been pivotal, and its continued evolution with projects like Jenkins X demonstrates an effort to adapt to the needs of modern, cloud-native environments. While Jenkins X has yet to reach the widespread adoption and maturity of its predecessor, its specialized focus on Kubernetes and GitOps reflects the shifting priorities in software development.

Jenkins, despite showing signs of plateauing in growth, still possesses a strong user base and an established presence in the market, supported by a vast plugin ecosystem and a robust community. Its limitations in cloud-native contexts—such as managing statefulness, configuration complexity, and supporting immutable infrastructure—pose challenges that Jenkins X seeks to address.

As we approach 2024, the relevance of Jenkins will likely hinge on its ability to integrate more seamlessly with cloud-native technologies and the willingness of the community to evolve its ecosystem. The breadth of its adoption and the depth of its integration in existing development pipelines mean Jenkins will continue to be a significant player in the DevOps toolchain. However, its long-term relevance will depend on the project’s ability to innovate and remain adaptable in a landscape that is rapidly embracing cloud-native solutions.

December 15, 2023
CloudBees CEO: State of Software Development is a Disaster

CloudBees CEO Anuj Kapur told attendees at a DevOps World event today that with developers spending only 30% of their time writing code the current state of software development in enterprise IT organizations is a disaster.

After more than 14 years of effort, the promise of DevOps—in terms of being able to accelerate the rate at which applications are being deployed—remains largely academic, said Kapur. In fact, the effort to shift more responsibility for application security further left toward developers has only increased the amount of cognitive load and reduced the amount of time available to write code, he noted.

However, with the rise of generative artificial intelligence (AI), an inflection point that will dramatically increase the velocity at which applications are being built and deployed has arrived, said Kapur. The challenge will be achieving that goal without increasing the cognitive load on developers. That cognitive overload results in 70% of developers’ time not being productive within organizations that often hire thousands of developers, he noted.

Despite all the DevOps issues that need to be addressed, AI advances promise improvement. The overall DevOps market is still relatively young, given the current level of adoption, said Kapur. “We continue to believe the market is early,” he said.

Today, CloudBees took the wraps off the first major update to the open source Jenkins continuous integration/continuous delivery (CI/CD) platform to have been made in the past several years. At the same time, the company also unveiled a DevSecOps platform based on Kubernetes that is optimized for building and deploying cloud-native applications based on portable Tekton pipelines. That latter platform provides the foundation through which CloudBees will, in the months ahead, apply generative AI to software engineering to, for example, create unit tests on the fly and automate rollbacks.

In addition, DevSecOps capabilities will be extended all the way out to the integrated development environments (IDE) to reduce the cognitive load of developers.

The overall goal is to reduce the number of manual processes that create bottlenecks that make it challenging to manage DevOps at scale.

Criticism of the level of developer productivity enabled by DevOps compared to other development approaches needs to be tempered, said Tapabrata Pal, vice president of architecture for Fidelity Investments, because it still represents a significant advance. There is still clearly too much toil, but the issues that impede the pace at which developers can effectively write code tend to be more cultural than technical, he added.

Organizations are not inclined to automatically trust the code created by developers, so consequently, there is still a lot of friction in the DevOps process, noted Pal.

In theory, advances in AI should reduce that friction, but it’s still early days in terms of the large language models (LLMs) that drive generative AI platforms and their ability to create reliable code, he added. That should improve as LLMs are specifically trained using high-quality code, but in the meantime, the pace at which substandard code might be generated could overwhelm DevOps processes until AI is applied there as well, said Pal.

Thomas Haver, master software engineer for M&T Bank, added that while assisted AI technologies will have a major impact, it’s not reasonable to expect large organizations to absorb them overnight. Patience will be required to ensure advances are made in ways that are both secure and sustainable, he added. In some cases, organizations may opt to build their own LLMs to achieve that goal, noted Haver. “You should not expect to change on a dime,” he said. “It will take time to see the fruits of our labor.”

While many DevOps challenges need to be resolved, the benefits continue to outweigh the cost and effort required to succeed. The hope is that, with the help of AI, the return on those investments will continue to accrue.

September 14, 2023
CloudBees Unfurls Dual CI/CD Strategy at DevOps World Event

During a DevOps World event, CloudBees took the wraps off the first major update to the open source Jenkins continuous integration/continuous delivery (CI/CD) platform made in the past several years.

At the same time, the company also unveiled a proprietary DevSecOps platform based on Kubernetes that is optimized for building and deploying cloud-native applications based on portable Tekton pipelines.

Shawn Ahmed, chief product officer for CloudBees, said the updates to Jenkins make it possible to horizontally scale Jenkins controllers while at the same time ensuring high availability. The latest update also provides a workspace caching mechanism to simplify sharing them across multiple jobs in a way that significantly reduces the amount of compute and storage resources consumed, he added.

CloudBees also added a Baseline capability to the Jenkins repository to improve startup times without causing build storms.
Collectively, those capabilities will increase the number of jobs that can be simultaneously executed to improve overall productivity, said Ahmed.

CloudBees has also added a Pipeline Explorer tool in the cloud-based edition of Jenkins that enables DevOps teams to visually debug and troubleshoot pipeline jobs. That tool will also provide the foundations for self-healing and artificial intelligence (AI) capabilities that CloudBees plans to add to the Jenkins platform later this year and into 2024, added Ahmed. For example, AI tools will surface suggestions on how to fix a problem in a pipeline, he noted.

The DevSecOps platform, meanwhile, leverages Tekton pipelines to provide DevOps teams with more granular control over how pipelines can be orchestrated, said Ahmed. It also provides access to GitHub Actions-style domain-specific language (DSL), support for feature flagging, security, compliance, pipeline orchestration capabilities, analytics and value stream management (VSM) tools that can be deployed by an internal IT team or accessed via a single or multi-tenant managed cloud service.

Those built-in capabilities will make it simpler for platform engineering teams to centrally manage building and deployment of cloud-native applications by enabling developers to self-service their own engineering requirements via an internal developer platform (IDP), said Ahmed. The overall goal is to provide a more integrated approach that breaks down software engineering silos that exist in many existing DevOps workflows, said Ahmed.

Each DevOps team will need to decide for themselves to what degree to move forward using Jenkins to build and deploy applications versus opting for a more modern alternative in the form of the DevSecOps platform. CloudBees, however, is committed to providing plug-ins and integrations across both platforms to enable DevOps teams to protect their investment in existing tooling, noted Ahmed.

The status of Jenkins X, an open source CI/CD platform based on Kubernetes that CloudBees previously donated to the Cloud Delivery Foundation (CDF), is not immediately clear. Regardless of the approach, however, there is a clear opportunity to revamp DevOps workflows by upgrading Jenkins or switching to a more modern platform such as DevSecOps. The challenge, as always, is determining the pace at which any such transition might be made.

September 14, 2023
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.

August 30, 2023
How Multiple Forms of AI Will Transform DevOps for the Better

The pace at which multiple classes of artificial intelligence (AI) are converging to automate DevOps workflows is about to accelerate the rate at which higher-quality applications will be both built and deployed. And this will happen at levels of scale once thought to be unimaginable.

Most recent AI advances have been squarely focused on using large language models (LLMs) to improve the productivity of developers. As valuable as that use case for AI may be, however, the volume of code moving through a continuous integration/continuous delivery (CI/CD) platform is only going to increase exponentially as developers become more productive. Most organizations are not going to be able to hire additional software engineers to manage additional pipelines, so the need to apply AI to DevOps workflows is becoming more pressing. Each passing day, more code is generated using tools that have been augmented in a way that makes it simpler to build higher-quality applications.

AI makes it possible to analyze large amounts of data in real-time to surface insights and optimize workflows. For example, the data analyzed by algorithms can identify where there are bottlenecks in a DevOps workflow, along with recommendations for how to break that logjam. DevOps teams can then apply machine learning algorithms to optimally configure a platform, otherwise known as AIOps, in a way that eliminates many of the manual tasks that make managing DevOps workflows more tedious and time-consuming than anybody wants. AI is also serving as a digital ‘pair programmer’ for many DevOps professionals, helping them think through problems and brainstorm innovative solutions quickly.

Generative AI tools go a step further—using natural language to instruct an LLM that has been trained to generate code to create the scripts that automate DevOps workflows. Those scripts can then be applied using an orchestration engine to automate CD processes at levels of unprecedented scale.

At the same time, organizations will also be able to use technologies such as a vector database to compare code against examples of other code that an LLM has been trained to recognize, with the goal being to identify defects in newly written code that might adversely impact application security. It’s now only a matter of time before the overall quality of the code finding its way into production environments improves to the point where the number of incidents a DevOps team has to respond to should start to decline steadily.

Realizing those benefits and other advances will require multiple types of AI models to be built and maintained. Companies such as CloudBees are making investments to define machine learning operations (MLOps) practices to build them. There will also be untold numbers of LLMs built by the open source community and enterprise IT organizations that will need to be integrated into DevOps workflows. The ability to review those models in a way that promotes transparency and trust will, of course, be crucial. As such, the value of an open CI/CD platform like Jenkins that makes it possible to embrace multiple classes of AI models simultaneously has never been more apparent.

Naturally, there is as much fear and trepidation about AI as there is excitement. No one knows for certain to what extent DevOps workflows might be automated, but there will always be a need for DevOps engineers to validate them. After all, it’s one thing to be wrong. It’s another thing to be wrong at scale. Mistakes that occur because of a flawed AI model could turn out to be catastrophic.

However, there is no going back. As multiple classes of AI technologies converge, DevOps teams will find can more easily manage DevOps workflows at scale. In fact, one of the long-standing criticisms of DevOps, in general, is how difficult it can be to manage workflows at scale. AI advances will soon effectively render that debate moot.

In the meantime, DevOps teams today would be well-advised to start reviewing their current workflows with an eye toward determining which processes can be automated. AI will soon be pervasively applied to drive a new era of software development that promises to dramatically accelerate the rate at which better applications can be built, deployed and updated. In fact, DevOps itself, thanks to the rise of AI, will soon be democratized in a way that will enable more organizations to embrace it, mainly because the level of programming expertise required will be significantly less.

As these changes occur, the number of applications that organizations can cost-effectively employ to drive an even wider range of digital processes is only going to increase. Exactly what impact all that software is about to have on the world as we know it remains to be seen, but the one thing that is for certain is that DevOps engineers will be at the center of it.

August 14, 2023
DevOps World: Time to Bring the Community Together Again
As a framework for building and deploying applications as fast as possible, DevOps has always been in a constant state of evolution. Over the past 10 years, there have been many seminal moments where major leaps forward have been made. As we near the end of 2023, it’s apparent we are collectively experiencing one of those times right now.

During multiple in-person DevOps World events taking place over the next several months in New York, Chicago, Santa Clara, Singapore and London, we’ll be exploring these advances as we celebrate all things DevOps. It’s always been our great privilege to host the DevOps community, and bringing that community back together to share insights and see first-hand how the latest and greatest technologies are transforming DevOps is an experience that no virtual meeting can ever replace.

DevOps is, above all else, a commitment to learning. The DevOps community is driving changes in the way applications are built and delivered that transform society. DevOps World creates an opportunity for the DevOps professionals at the forefront of those efforts to see for themselves how a raft of emerging innovations will take DevOps to the next level.

DevOps World attendees, for example, will be discussing topics ranging from how generative AI will be applied to how changing compliance requirements will impact software delivery. In addition, there will be deep dives into the impact advanced analytics are having on breaking logjams. There will even be demos showing how digital twin technologies will be used to modernize DevOps workflows.

Just as important, DevOps World provides an opportunity for attendees of all skill levels to network with their peers and advance their education. We all know that virtual training can be challenging. In many instances, there simply is no substitute for being in a classroom with an instructor and fellow students all focused on the same topic at the same time. Careers are made at our DevOps World events. In fact, several sessions will show how investments in the venerable Jenkins continuous integration/continuous delivery (CI/CD) platform will be carried forward into the next era of application development and deployment.

Naturally, many of us wonder what our future career paths will look like in the age of AI. It’s already been shown that natural language interfaces will make AI a lot more accessible to everyone in IT. More and more, the bottlenecks and associated manual effort that often conspire to adversely impact DevOps productivity are about to be eliminated. For example:
- The days when an engineer was required to create a simple script are coming to an end.
- The average IT administrator should be able to automate a process using a few simple prompts.
- Tools will become increasingly intelligent in their ability to detect the root cause of issues without causing alert storms.
The challenge now is training the large language models (LLMs) needed to apply generative AI to the DevOps domain. CloudBees is proud to be at the forefront of an effort to enable organizations to safely apply AI to DevOps workflows at scale in a way that can be trusted.

In the meantime, DevOps teams should be evaluating which tasks AI will be able to automate both today and tomorrow. Roles and job functions will evolve accordingly, but DevOps engineer roles are not going to be made obsolete any time soon. Instead, AI will free DevOps engineers to spend more time solving complex issues rather than performing rote tasks that are better handled by machines. A commitment to automation remains a foundational DevOps principle. Anything that can be automated should be.

As always, luminaries from the global DevOps ecosystem will present at DevOps World. The best and brightest practitioners from across the DevOps spectrum, along with our premier technology vendor partners, will be readily accessible to attendees. The opportunity to learn from others is the whole reason DevOps World events exist in the first place. More than 40 speakers, including DevOps experts from Argonne National Labs, Autodesk, Fidelity Investments, GitHub, Gradle, M&T Bank, MFS, Postman, Software Engineering Institute/Carnegie Mellon, Sonatype and Veeam Technologies have already committed to sharing their insights, and we expect many more as the event approaches.

DevOps has never been more crucial for any organization that is dependent on software to modernize than it is right now. The pace at which applications will be built and deployed in the AI era is about to exponentially increase. There will always be a need for DevOps engineers to manage application development and deployment. The opportunity for attendees at DevOps World is to collectively define the next generation of DevOps best practices with AI in mind. Reserve your metro New York, Chicago, Santa Clara, Singapore or London spot at DevOps World today!
August 8, 2023
Strategies To Consider When Adopting Platform Engineering
Platform engineering helps centralize the responsibilities associated with maintaining internal infrastructure. And it continues to be an emerging discipline—according to the 2023 State of DevOps Report, 51% of organizations have already adopted platform engineering within the last three years, and 93% said it’s a step in the right direction.

I recently met with Hope Lynch, senior director of platform at Cloudbees, to gain some insights on implementing platform engineering. According to Lynch, platform engineering has emerged at a critical juncture. Developers are overloaded, burnout is on the rise and tooling sprawl is starting to rear its ugly head. To respond to these trends, platform engineering has emerged to take the heavy load off internal software infrastructure management. But the practice requires keenly balancing responsibility with control and treating the platform as a product.

Interestingly, Lynch believes that many IT departments—whether they know it or not—are already implementing some form of platform engineering. They might just need to work out the kinks. Below, we’ll define platform engineering as it relates to DevOps and share some best practices to consider when rolling out (or reiterating) a platform engineering plan within your organization.

State of DevOps and Platform Engineering

So, what is the state of platform engineering and DevOps? Contrary to the salacious ‘DevOps is dead,’ headlines, Lynch doesn’t believe DevOps is going anywhere. Instead, platform engineering is helping overburdened developers, having emerged at a time when developers and operations seem to be at a crossroads.

Developers are now responsible for coding, security, deployment and infrastructure maintenance. “Developers are talented and creative, but everyone has only so much capacity,” said Lynch. She believes platform teams can relieve some of these pressures by creating standard builds and common CI/CD pipelines. “I see it as a partnership between the DevOps teams and platform operations teams.”

Lynch views DevOps as more of a practice than a specific job title. And although developers should have control over their DevOps toolchain, she believes they were granted too much responsibility. For example, the amount of effort required to search the market, talk to vendors, and try out tools can all add up significantly.

By creating proven patterns and managing tools, platform engineering teams can help narrow down the options, working behind the scenes to ensure the platform is self-serviceable and continually updated. Of course, this partnership requires regularly collecting feedback to ensure platform teams are enhancing development workflows, not hindering them.

Best Practices for Platform Engineering Adoption

So, what are some best practices that enterprises can apply to their internal DevOps platforms? Lynch shared some areas platform engineering teams should focus on to improve their process. By following these tips, a platform can enhance DevOps principles within a company.
- Be open to feedback from developers. As previously mentioned, platform engineering and development should be partners. Platform engineers should seek to gather as much feedback as possible from developers to improve their experiences and ensure the right DevOps tools are acquired.
- Don’t control everything. As such, a degree of flexibility should be granted—you don’t want to mandate standardized adoption of all tools. Yet, you do want to decrease rogue tooling and sprawl. The platform team should thus work to find a balance and build trust.
- Maintain a DevOps culture. When people discuss DevOps, they often talk about the tools and technology, not why DevOps came to be. “DevOps is here because we were trying to find a way to allow teams to work better together and be high-performing,” said Lynch. As such, we shouldn’t forget to include the people element here. Platform engineering should reinforce a healthy culture with positive dialogues and ensure work is “a fantastic place to be.”
- Treat the platform as a product. When delivering internal-facing tools, your developers are your consumers. Thus, it’s a good practice to treat the platform as a product in its own right. This includes publishing roadmaps and eliciting feedback. “The platform team really needs to win the business of their internal customers, or else they’ll buy or use something else, which could cause shadow IT.”
- Focus on increasing developer experience. As part of viewing internal developers as customers, platform teams should invest in improving the developer experience associated with using the platform. This means reducing friction and integrating new capabilities into preexisting workflows whenever possible.
Goalposts For Platform Engineering Success

For any new initiative to be successful, it must have goalposts and be measured in some capacity. The same is true for platform engineering. So, what are some goalposts that IT leaders should have in mind when introducing platform engineering? According to Lynch, some positive end results include collaboration and efficiency, cost analysis, cybersecurity and tooling centralization.
- Collaboration and efficiency: First, platform engineering should improve work in the best way for everyone, says Lynch. “The people component is always there and should always be a priority,” said Lynch. To reach these goals, she recommends having the right conversations to co-discover bottlenecks in the value stream management of software development.
- Cost optimizations: Secondly, platform engineering is an opportunity for garnering insight into usage rates, which could inform cloud cost analysis. Platform teams can implement specific policies, such as spinning resources up or down to reduce expenses.
- Improved security: Platform engineering teams can be the first to test new products, giving them a unique opportunity to synchronize requirements with security teams. They can also take the reins of continually patching dependencies to reduce vulnerabilities.
- Increasing consistency. In general, another benefit is centralizing tooling control. Because when tens and thousands of developers are each using their own tool, it becomes harder for teams to work together. While some cutting-edge technology organizations may seek to give developers control over the full cycle to increase agility, most will benefit from centralizing procurement and oversight, said Lynch.
The Human Side of Platform Engineering

“Platform engineering, when done right, furthers the principles of DevOps,” said Lynch. And interestingly, it may be the case that teams don’t even realize they are already doing platform engineering. Once they realize they are gravitating toward these ideals, it will be an even greater reinforcer for DevOps and DevOps principles, she said.

Currently, the tech space is in a tricky spot, with rising layoffs and tightening budgets. At many organizations, fewer people are now expected to perform the same high caliber of work. As a result, we need to place more emphasis on retaining the remaining talent and boosting morale. This means caring about what the developer’s experience is like throughout the day and supporting the human side of DevOps. According to Lynch, platform engineering is a natural choice in these circumstances.
February 23, 2023