Tag: Software Delivery Management

Editor’s Note: This blog post is the second in a series about Software Delivery Management written by Shawn Ahmed, vice president of product marketing. 

Software Delivery Management is finally here and we’re all part of making history to launch CloudBees into this emerging category.

I know each keynote during a conference is important, but sitting in the audience during DevOps World | Jenkins World 2019 in San Francisco was truly a defining and pivotal moment for our company.  Shawn Ahmed, vice president of product marketing, and the team launched CloudBees into the emerging category of Software Delivery Management. You could feel the excitement in the air. It was tangible.

In my mind, Shawn’s explanation can be boiled down to one sentence: SDM lets you see what’s going on in your dev cycle, produce better software and deliver it into the hands of users while adding more value to the customers. Of course, it’s an oversimplification because Software Delivery Management relies on four pillars including common data, connected processes, universal insights and all functions collaborating to bring it all together. But if you were to ask a non-developer like me to describe SDM, it’s what I would say.

What made Software Delivery Management relatable to me, and I suspect many others, was Shawn’s personal backstory of the problem plaguing software development companies today.

Before SDM

Indeed, Shawn began the keynote by sharing his personal story of being an engineering manager for a software company who developed applications for financial services.

These were highly regulated companies under intense pressure to make the digital transformation, but the stakes for getting software right were high, he recalled. Shawn’s company had six months before their investment funds ran out and they needed to increase revenue without increasing their team of 100 developers. Not an easy task, at all.

Shawn investigated what happened with the development team. His findings? They wasted time each morning sorting through six or seven tools to see what they should work on, and then wondered what happened to the feature they even worked on. It was a black hole. Developers didn’t know when their feature would be released or what was holding it back.

Shawn also found the operations team had similar frustrations. They were responsible for making sure applications met the clients’ compliance requirements. But the ops team had no context for any particular feature that came through the pipeline. Who wrote the code? Why was the feature developed?

But it was the engineering managers who finally woke him up, Shawn said. His engineering managers were doing their best to get everyone on the same page, see and eliminate bottlenecks and speed up the development and delivery process. But the hurdle? They were trying to manually collect data from dozens of DevOps tools and it was never current.

Everyone in the engineering department was operating off different data sets, Shawn explained. Getting a full, birds-eye view of the entire software stream was essentially impossible.

Seeing the importance of getting the full value of the value stream and working off a set of common data to collaborate more efficiently enabled Shawn to “see” the proverbial light.

They developed a custom solution to give everyone in the software organization access to real-time, common data, Shawn recalled. Just that one step increased efficiency dramatically. Meetings and calls dropped precipitously. They no longer had to do time-consuming forensic investigations into bugs or bottlenecks, he said.

Customers were thrilled. The jump in efficiency meant Shawn’s team could take on more projects, increasing revenue. Of course, investors were thrilled, too—and then the company was quickly acquired.

After the acquisition, Shawn got a call from CloudBees, asking if he’d be willing to help create a new category: Software Delivery Management.

And that’s how it all began.

What is Software Delivery Management?

The goal of Software Delivery Management is to provide a way for companies—from small, 100-developer organizations to developer teams with over 10,000—a way to use common data throughout the entire software organization. This allows for development to become much more efficient so that other stakeholders in other parts of the organization – not only from the development teams but also doc writers, product management, product marketing, customer support, and others can work off the same set of data. Everyone is on the same page.

Using common data, this leads to better collaboration among the different stakeholders throughout the organization with connected processes. A truly seamless collaboration environment gives everyone universal insights to see what’s going on.

With Software Delivery Management, organizations have the ability to use one interface to query the entire DevOps toolchain—and everyone in the software organization can run any query and access the same data. Managers can set organization-wide policies and set up alerts or automated actions when policies are broken. There’s also a Recommendations Engine to surface information about common bottlenecks and provide recommendations for how to eliminate them.

Here’s how it works:

• One dashboard pulls data from the multitude of tools that teams across the software organization are using, from tools like Jenkins and Jira to observability and monitoring tools. This data is displayed in one place, with context, to give anyone in the software organization visibility into the complete pipeline.

• The Value Stream View lets engineering managers—or anyone else—see how features move through the lifecycle, from idea to production. This lets you see where features are stuck in the process and easily troubleshoot. Teams can be automatically alerted when their feature is delayed and proactively troubleshoot.
• The Policy Engine lets organizations set rules for alerts. For example, a team should be alerted if a pull request is waiting more than seven days for a review. Not only are the policies customizable, but teams can also customize what action should be taken when a policy is broken.
• Developers can immediately see what the top priorities are, with a personalized daily morning brief. Clicking on this morning brief takes developers to a Contributions Dashboard that lets developers easily see how their work fits into the team’s workflow.

• Developers are also given access before development is started, what the original problem statement is and the original RFE.

And that’s just the beginning of SDM.

You can watch Shawn’s full keynote below or head to CloudBees TV. For more information about CloudBees and SDM, sign up for the CloudBees solution for SDM Preview Program.

 

Overview

The digital economy has pushed organizations to produce better products faster, leading them to adopt DevOps and continuous integration/continuous delivery (CI/CD) for efficient software delivery. This industry shift impacts all groups within an organization to evaluate and adopt new business practices to meet this growing need and stay competitive in the market.

Indeed, IT leaders implemented DevOps practices and tools to achieve modern software development, but it’s unclear to them whether there is any return on investment (ROI). Product and engineering leaders struggle with determining how to measure and manage their software delivery capability. The complexity of multiple teams, tools and applications means the whole process can be disconnected and difficult to track. Adding to this challenging scenario, today CIOs are measured on delivering quality software products, with zero defects that engage customers and generate revenue.

What is value stream management?

A value stream consists of a series of steps used by an organization to continuously deliver value to customers. Value stream management is a practice that enables the organization to track and manage the flow of value from the ideation stage all the way to customer delivery. Proper value stream management ensures the facets related to end-to-end software development are connected and measured to properly and efficiently move the flow of value related to a product or service to the customer.

But when we start talking about value stream management, you need to think about value stream mapping as well. Value stream mapping is the exercise of visualizing the process of events that takes a product from idea, to creation, testing, production and finally release to the customer. Mapping the value stream of a product helps you understand how the artifacts and workflow, the dependencies at each stage and identifying the blockages or bottlenecks that result in waste and delay delivering value.

Why track value streams?

Managing your value streams lets you focus on delivering value to the customer. To do this, you need to connect multiple teams, tools and applications to gain clear visibility and insight into how the value is flowing through the software delivery process. This means having a platform that scales easily and enables collaboration, while reducing risk, along with accessing real-time metrics on DevOps performance across the teams, and tracking throughput and stability related to product releases. The goal is to deliver quality software at speed that your customers want in order to drive value back to the organization.

In short, value stream management can help you solve these challenges:

• Poor visibility across the software delivery process makes it difficult to measure and manage DevOps performance – to identify improvements, leverage best practices and support collaboration across teams.
• No connection between applications, teams and tools means intensive, error-prone methods of collecting static data for measuring and managing the organization’s continuous delivery capabilities.
• Difficulty in end-to-end value stream management resulting in lack of information to track flow of value from idea to production, and guesswork on identifying bottlenecks and wait times, leading to increased waste and delays in delivering value.
• Lack of real-time performance metrics to benchmark and track DevOps performance based on industry standard indicators related to Throughput (Deployment Frequency, Mean Lead Time) and Stability (Mean Time To Recover, Change Failure Rate).

What does a good value stream management platform look like?

As your software delivery processes become more complex, you’ll need a value stream management solution that provides one view across the infrastructure, with data and metrics that can be trusted, in order to truly report on how the organization’s DevOps performance is progressing. You should look for the following:

• A scalable and flexible CI/CD solution that enforces an organization’s governance needs.
• A solution that easily maps, actively measures and manages your value streams, acting as a single source of truth to analyze and continually improve the flow of value.
• Real-time performance metrics related to Throughput (Deployment Frequency, Mean Lead Time) and Stability. (Mean Time To Recover, Change Failure Rate).

CloudBees solution

The CloudBees suite of CloudBees Core and CloudBees DevOptics makes value stream management easy. The solution provides a CI/CD automation engine with the flexibility to support diverse software portfolios and the unified governance required by growing organizations. Based on Jenkins, CloudBees Core extends Jenkins with functionality that embeds best practices, rapid onboarding, security and compliance. It provides a shared, centrally-managed CI/CD service but delivers a self-service experience for engineering teams.

By connecting data from across the DevOps toolchain to surface metrics, analytics and actionable insights, CloudBees DevOptics helps you optimize your software delivery process by breaking down silos, detect patterns and identify bottlenecks. It visualizes the software delivery process using key DevOps performance metrics including: Deployment Frequency (DF), Mean Lead Time (MLT), Mean Time To Recover (MTTR) and Change Failure Rate (CFR), to truly understand the velocity and quality of the software being deployed, and where your teams can improve.

Additional resources

• Gain insight into software delivery value streams with CloudBees DevOptics
• Listen to a podcast on value stream mapping the DevOps journey
• Watch a webinar on value stream management and DevOps workflow

If you were amongst the attendees of our first few CloudBees Days events of 2019, in Madrid April 4, Zurich April 10, or yesterday in Dallas April 16, you witnessed us introducing the world to a new category of software we are inventing here at CloudBees: Software Delivery Management, or SDM (yeah, I know the world needs another TLA – sorry.) Tomorrow at the San Francisco event, we have a big announcement that is key to us realizing this new vision.

So what is Software Delivery Management, or SDM? Why does the world need it?

Well, at the most basic level, with “software eating the world,” every company in the world is learning how to be a software company. That means that every company is trying to get better at delivering software. This is a big change for many from the time when software development in most companies was the province of IT as a cost center. This is what “digital transformation” is about. Software development organizations are now the engines of innovation at the companies that have transformed most quickly.

Digital Natives like Facebook, Netflix, Amazon, Google and the like as well as scores of fast moving startups have pioneered a set of continuous integration, delivery and deployment practices (CI/CD) as well as industrialized agile and DevOps methodologies to deliver new releases to their customers, 1000s of times more frequently, with higher quality, fewer defects and faster time to recover.

Even software companies like us are learning to be more effective software companies to keep up, and essentially going through our own digital transformations.

These transformations usually start with adopting CI/CD, agile and DevOps tools, practices and cultures. At CloudBees, as the leading CI/CD vendor to enterprises in the world, with nearly 50% of the Fortune 100 amongst our 1000s of customers, and the corporate sponsor of Jenkins, the dominant CI/CD automation server in the world, we have a front row seat to this mad dash. In the last year, we’ve seen these initiatives move from important to top level urgency at the largest companies in the world.

But once these transforming companies start seeing faster and better software through these practices, they start to see other problems.

People outside of engineering have a hard time knowing what’s been deployed. Engineers working on a feature are disconnected from the user and market input that drove product management to prioritize the feature. A feature might be behind a feature flag but customer success doesn’t know what enabling the feature for a customer will do exactly. Roadmaps are increasingly irrelevant so marketing and sales feel like they don’t know what’s coming down the line to make the most of the innovation in the market. Engineering doesn’t know what changes in system performance or user behavior resulted specifically from their latest change. Senior management doesn’t have a trustworthy view of value moving through the system and the business impact of this faster pace of innovation.

For a new greenfield product built to be buzzword compliant from the start – cloud native, microservices on Kubernetes or serverless, etc. – some of the newer generation cloud native CD tools (like our own Jenkins X) + some of the latest generation observability tools may solve these problems to an extent, and from a developer’s perspective – seeing how their feature flows through to, and performs in, production.

But that’s not the reality of software development in an organization of any complexity in terms of sheer size, the diversity of software being developed and environments to which it is being delivered, and the range of stakeholders who legitimately care when software is at the center of the business. In our Madrid event this month, I was really struck by how many attendees in roles like head of DevOps transformation talked about the impedance mismatches with other functions of the business once software development becomes truly continuous and agile – this is what I’ve written about before as “Continuous Everything.”

So Software Delivery Management (SDM) is the new category of software system that we are inventing to solve this problem of getting every function in and beyond the software delivery organization on the same page. On the same page about what’s being or been delivered, why, and its impact. Ensuring that the entire organization can have connected processes on top of a common real time view of the truth. That encompasses the entirety of diverse software product portfolios, from mainframe to microservices, on premise to public cloud, embedded to mobile, and beyond.

SDM will be for the software development organization what Salesforce.com is for the sales organization, NetSuite is for finance and Workday is for HR.

Like the best of these systems, it serves all roles and all levels in the organizations that use them. For SDM, our aim is that even developers find that using such a system doesn’t control them, but sets them free by giving them all the context they need to build software that has an impact – and the ability to see that impact in concrete ways. And other roles can interact with software development in a supportive rather than disruptive way. While pointy-haired bosses like me stay out of their way when we can see that things are humming along. Together, everyone in an organization using SDM cooperates fluidly with one another to “Build Stuff that Matters.”

Watch this space in the coming weeks and months for more detail on what the building blocks of an SDM are, how it will benefit different people in different roles in software organizations, and how we’re using our own internal experiences at CloudBees to inform its design.

Meanwhile, the foundation of software delivery management as a category and as a practice is CI/CD, and choosing CloudBees for CI/CD today is the best first step on that journey we will hopefully take together.

Today, open source communities use a wide range of tools for building and delivering their software. These tools tend to also be open source, but more and more open source communities are starting to see the value of managed, SaaS tools to help support their communities and their goals. Still, finding the right fit can be a challenge – you want tools that help developers but also support the values of the open source community. Factors like hosting, cost, scalability and integration support play a crucial role in making these choices. In this post, I’ll take a look at why SaaS solutions are often the right choice for open source, and why they may be the right choice for your own continuous integration/continuous delivery (CI/CD) open source project.

While Jenkins is most open source projects’ default choice for CI/CD – and often rightly so – it’s not the only thing your team should consider. These days, teams working in open source projects have also started using various SaaS tools (Heroku, GitHub, JFrog, etc.) for their infrastructure and portions of their CI/CD pipeline. Still, somehow, they are reluctant to use hosted CI servers. This raises the point – if you can trust Heroku for your open source projects, then why shouldn’t you trust a SaaS CI/CD provider whose core business is based on the same service?

Why SaaS?

Sometimes, an open source community may decide to use a hosted, SaaS tool so that it’s one less piece of infrastructure they have to oversee and manage or to keep newer projects at the lowest level of community governance and decision-making needed for as long as possible. Cloud-based CI/CD solutions delivered on SaaS models can help let communities move fast and worry less for a variety of reasons:

• Cost. For open source projects, most of the SaaS CI/CD tools are available free of cost.
• Security. Organizations keen on security and compliance can adopt a hybrid approach, where they can host their code on servers running in private networks and run CI/CD builds in the cloud. This lets the CI/CD service own the security problems, which is one less thing for a community to worry about.
• Efficiency. SaaS CI/CD, such as CloudBees CodeShip, are optimized for speed and flexibility with no overhead or management to achieve those goals.
• Simplicity. It’s easy to get started with SaaS CI/CD; provisioning can be done within a few clicks (discussed below). It is ideal for small teams managing the entire CI/CD setup as it significantly reduces overheads in the development and deployment process.

Out-of-the-box CI/CD solutions

A lot of teams and individual developers prefer to work with out-of-the-box cloud-based CI/CD solutions like CloudBees CodeShip, which one can use for free for their open source projects. That’s because, in addition to the cost advantage and ease of setup, cloud-based hosting means there are no administration and maintenance – from version updated, to security patches to world-class technical support -everything is handled for you and made simple. With no hardware or software infrastructure to procure and maintain, teams can focus on working on their projects and writing high-quality code, not on infrastructure.

That is why organizations starting with small open source projects often find out-of-the-box SaaS CI/CD solutions useful as they make it possible to start small and scale up when required. The SaaS model enables easy scalability allowing developers to perform a higher number of commits, provision larger build machines for tests and use parallel pipelines. Therefore, these solutions are very popular in the CI/CD market. The tradeoff is that such solutions are not suited for all organizations as they offer limited flexibility for customization.

The bottom line

Teams comfortable with open source often cite a lack of openness in SaaS solutions as a major concern. However, vendors have gradually started exploring the benefits of open source; the biggest and most commonly cited example is that of Microsoft which has embraced open source as well as SaaS in recent years. Similar trends in the industry suggest that SaaS and open source will complement each other more in the future and certainly aren’t at loggerheads. In fact, SaaS-based software delivery solutions like CloudBees CodeShip are gaining acceptance among open source communities – which suggests that the future of such solutions is bright.

SaaS CI/CD solutions like CloudBees CodeShip fits a variety of open-source and private projects, offering better scalability, customization and ease of use. Moreover, as these solutions are generally free, teams using Jenkins-based solutions can easily try the CloudBees CodeShip CI/CD solution in their environment and make an informed decision for its adoption with their open source projects.

Additional resources

• Learn the best practices to get started with CI/CD
• Find out more about the CloudBees CodeShip beta with new unified build
• Read the tips on running parallel test pipelines with CloudBees CodeShip

From conferences to articles and books, the term DevOps has taken the IT world by storm. The buzz is understandable, as many IT groups are looking for a way out of the morass of delayed projects, questionable quality and missed deliveries in which they often find themselves.

It’s clear DevOps has potential to address the challenges IT faces. Organizations that have embraced DevOps – including companies such as Etsy, Netflix, Target, Walmart, Ticketmaster, Amazon and Facebook – have shown that DevOps principles can lead to competitive differentiation by enabling teams to deliver higher quality software at the speed required with customer expectations of 24/7 uptime and instant access. As a result, it’s not a stretch to say DevOps is becoming the industry standard for software development.

Why DevOps anyway?

A little more than 100 years ago, the automotive industry was revolutionized by the first moving assembly line. Once industrialization and automation were applied to dramatically reduce the time required to produce an automobile, there simply was no going back. Certainly a few car manufacturers resisted the change, clinging to their existing approach, but the holdouts all eventually adapted or they perished.

Companies that have adopted DevOps principles are innovating faster and leaving competitors behind. So what is the DevOps culture and why do we need it? By changing to a DevOps culture, these companies have aligned all stakeholders – from dev and ops teams to management and more – around the common objective of delivering quality software rapidly and reliably.

Today’s technically savvy customers expect immediate access to the benefits of technological innovation and they’ve grown increasingly intolerant of software that is buggy, unstable or not secure. Customer expectations are driving what is known as the continuous economy, in which customers experience a business through its software and how they deliver it using continuous integration/continuous delivery (CI/CD). In this economy, technology is a business enabler and the ability to reliably deliver quality software is critical.

Organizations will need to transition to DevOps soon to remain competitive in the continuous economy – even to stay relevant. This may sound like hyperbole, but an increasing number of companies are finding out the hard way that almost every company is a software company and that DevOps is a common sense way to gain a sustainable, competitive business advantage. In addition, developers will seek employment at companies where they can innovate instead of fight fires all day.

Even companies in industries far afield from software have found that they need to make software companies part of their core business. Take Ford Motor Company. You may not think of trucks as software, but the Ford F-150 truck features more than 150 million lines of code. A lead engineer on the Ford EcoBoost engine team noted that the “secret sauce” in the success of EcoBoost technology is software.

There is no going back. It’s safe to assume that your more successful competitors will be embracing DevOps sometime within the next five years. The question you must answer is, “Where will your organization be in five years?”

Why you should care about DevOps

Simply put, companies that have embraced DevOps are better positioned to solidify their position in existing markets and expand into new ones. Indeed, adopting DevOps is rapidly becoming the de facto standard for software development. A quick look at industry examples – think Apple, Netflix, Tesla, Uber, AirBnB and many others – reveals early successes and tremendous potential.

Once DevOps is implemented, companies have seen an increase in satisfaction for development process stakeholders. Because they are applying modern software development practices, these companies are attracting and retaining better talent, who will drive further quality improvements, productivity improvements and ultimately success at the company. When developers no longer perform tedious, rote manual coding tasks and are free to innovate and make a difference, they are happier.

A large financial software company saw a 15 percent improvement in employee satisfaction just weeks after adopting CD in support of DevOps principles. Just as important, a happier and more engaged workforce means increased productivity, lower costs and better software.

At the end of the day, any company that needs to deliver quality software faster needs to care about DevOps and the supporting practice of CD, which enable continuously building, testing and deploying software in frequent, incremental releases.

Companies that fail to embrace DevOps will bleed talent and fall further behind their competition, serving as illustrations of the adapt-or-perish maxim that is as true in the software development world as it is in the natural world.  Which company do you want to work at?

What is the DevOps model?

There’s been a lot of talk about what DevOps is and is not, but recent consensus is that DevOps is primarily about culture. Organizations that have adopted this culture value collaboration, experimentation and learning. In a DevOps culture, all participants in all phases of the software delivery lifecycle align around a shared goal: the rapid delivery of stable, high-quality software from concept to customer.

Automation of software development, testing and deployment through continuous delivery goes hand-in-hand with DevOps. Automation enables organizations to deliver software more quickly while ensuring operations can have confidence in what is being deployed, and customers get the quality, security and stability they require.

The DevOps trinity

At its core, DevOps is being about gaining alignment between all software development lifecycle participants on three planes – people, process and tools – often called the DevOps trinity. In this framework, the software development lifecycle is viewed as having upstream (development) and downstream (operations) halves. The two halves are part of the same software delivery process but in many traditional IT organizations these halves are highly disconnected (Figure 1).

Figure 1: The disconnect between upstream and downstream people, process and tools.

Upstream, the development culture usually prioritizes speed and innovation, whereas downstream the operations culture is tasked with a focus on maintaining quality, stability and uptime. Upstream, development uses point tools to define and build software using agile methods. Downstream, enterprise class tools are the norm for managing the test, release, deployment and operation of the software.

Downstream meetings are much more likely to be filled with talk of Information Technology Infrastructure Library (ITIL) and Project Management Body of Knowledge (PMBOK) than Kanban and the latest scrum. DevOps is about connecting these worlds and eliminating the chasm that exists between the upstream and the downstream.A look at the “How” of DevOps

Often, discussions on the how of DevOps are too narrowly focused on the technical core of what happens from the time developers commit code to the time software is deployed to a server. In reality, DevOps extends from the initial concept to the customer deployment.

The full DevOps cycle starts with understanding the customer’s needs. Once they are clear, then you create a plan to define a solution, a plan to deliver it and a plan to support it once it moves into operation, where you gather customer feedback and the whole cycle begins again.

Figure 2: Agile methods, continuous integration and continuous delivery provide the foundation for a DevOps transformation.

DevOps –fad or here to stay?

Anyone who’s been in the software industry for any length of time has seen fads come and go. The buzz for software-oriented architectures (SOA) was all the rage a few years ago, but that buzz faded to a whisper.  Waterfall methods are fading fast, replaced by agile development. How can you tell if DevOps is just the latest in a line of operational strategies that will fade out?According to a Harvard Business Review survey sponsored by Google, 86 percent of the 654 respondents say that it is important to their company to develop and put new software into production quickly. That leaves 14 percent who do not realize that they need solutions like DevOps. At times like this, it pays to step back, take a breath and take stock of where we are and where we are going. When we do, it becomes clear that DevOps is not a fad; rather it is the way successful organizations are industrializing the delivery of quality software today and will be the new baseline tomorrow and for years to come.

DevOps today

When research shows that most companies surveyed are planning to or are already transitioning to DevOps enabled by CD, that speaks to the current popularity of DevOps. In taking a closer look at the companies that have already adopted CD practices and a DevOps culture, many of these companies are the established leaders in their respective industries and hold a dominant market position. Having made substantial, long-term investments in CD and DevOps, they are already seeing impressive benefits. For example:

• Amazon, the leader in public cloud infrastructure, now releases on average every second
• Etsy, the leading peer-to-peer e-commerce marketplace, went from deployments that took hours to deploying changes 50 times per day
• Ticketmaster, the world’s leading ticketing company and one of the world’s top 10 e-commerce sites, deploys to production at the end of every sprint or multiple times per sprint
• Netflix, disrupter of the entire cable and TV industry and responsible for about 30 percent of North American internet traffic, deploys thousands of times daily
• Nordstrom, a leading fashion specialty retailer with 323 stores in the U.S., increased the pace of releases to monthly from just twice per year
• Allstate, the largest publicly held personal lines property and casualty insurer in the U.S. is now delivering new applications in half the time it took to deploy a single new feature
• Coca Cola, the world’s third most valuable brand, has accelerated project delivery as much as 50 percent and cut defects in production by about half

While some organizations have resisted making a DevOps transition – either due to confusion about what DevOps entails, concerns that it may just be a passing fad or a simple aversion to change – other organizations have jumped in with both feet.

The organizations who’ve made the jump are eager to reap the benefits being realized by competitors and other companies that have already transitioned to a continuous delivery and a DevOps culture. These companies are differentiating themselves and delivering higher quality software faster by aligning development and operations across the DevOps trinity – people and culture, process and practice, and tools and technology. Better alignment across these three planes enables organizations to improve time to production, drive business value and reduce IT costs.

CloudBees drives DevOps, CI and CD

The CloudBees Suite enables companies to automate their software delivery with a layer of visibility and governance all built on DevOps and CI and CD best practices. CloudBees Core delivers Jenkins for the enterprise with a tested and verified Jenkins core, advanced enterprise features that extend the power of Jenkins, fully-tested updates and professional support for the Jenkins core and all 1,500 community plugins. The flagship offering provides high availability to support continuous delivery processes, as well as simplified manageability, security and scalability of Jenkins to ease administration across distributed Jenkins environments and IT architectures, on-premise or in the cloud.

CloudBees DevOptics offers businesses the visibility into the software delivery pipelines to visualize their value streams and determine their DevOps performance based on industry metrics. CloudBees CodeShip enables teams to get up and running fast using CI/CD as a service while the CloudBees Starter Kit gets teams up and running for free with CloudBees Core and CloudBees DevOptics.

DevOps customers including Capital One, IHG, Autodesk, Mabl and a host of others can attest to their DevOps transformations using CloudBees products. See what they’ve done by reading their case studies and decide on whether deploying a DevOps model is best for you.

Where will your organization be in five years?

Additional resources

• Listen to a podcast on how to make DevOps happen with data
• Learn about the state of DevOps and why the cloud is important to CI/CD
• Discover why DevOps is here to stay
• Download the DevOps whitepaper