Autodesk embraces DevOps, CI & CD to strengthen its competitive market position and deliver higher quality software and features to its customers even faster.
I am convinced that we could not have done this without CloudBees.
An easy, quick move to Jenkins X saves hours for Simplified Telephony Solutions developers, freeing up their time to focus on code, quality and customers.
My favorite thing about Jenkins X is it really is a one size fits all solution. From day one, it just worked. Now we have more time to focus on what’s important – our code, our software and our customers.
[su_youtube url=”https://www.youtube.com/watch?v=EUPq3WQ1Y98&feature=youtu.be”]
Software Delivery Management breaks down silos, providing visibility across an organization into the software development lifecycle. It relies on four foundational pillars:
These pillars support a unified system of record in which all functions can enjoy continuous insights and feedback, resulting in faster software delivery and positive impact on the business.
To learn more about SDM, this whitepaper will help you understand how and why SDM is evolving and the benefits it will provide to your organization. Break down the silos and see how the business of DevOps and Software Delivery Management can transform your organization into a faster software delivery machine.
[su_button url=”https://www.cloudbees.com/resource/whitepaper/continuous-everything-why-software-delivery-management-matters” target=”blank” background=”#ef2d3f”]Download Now[/su_button]
Editor’s Note: This is the third blog in a series about Software Delivery Management written by Shawn Ahmed, CloudBees vice president of product marketing.
Today, I’m so excited to announce CloudBees’ entry into the Software Delivery Management (SDM) market with our solution for SDM. It’s been a long time coming, in which CloudBees has reimagined how we could tie all the disparate and siloed tools from across an organization’s teams and departments to provide better, software faster.
In my previous blog posts, I talked about recognizing the limitations and gaps we see in DevOps and software delivery today. We know there’s little controversy about the benefits of a mature continuous integration/continuous delivery (CI/CD) pipeline. They include reducing the failure rate for changes to under 15% from over 50%, recovery time after downtime measured in minutes instead of weeks and cycle times measured in hours, not weeks. CI/CD helps enterprises deliver software that works better, from a technical standpoint: better performance, fewer failures.
But there’s a limit to what CI/CD can provide to all those organizations undergoing their own DevOps transformation today. CI/CD only connects the parts of the software lifecycle that happen inside the software engineering department. It starts with a bug or feature ticket and ends with a deployment. But when you talk to developers, engineering managers, operations and other stakeholders, they will tell you that things still aren’t perfect. Even if they are able to implement multiple best practices, and achieve the quality and velocity promised with effective CI/CD and DevOps, there is still work to do. Developers don’t have visibility into the real business or customer need, or adoption; engineering management is still scrambling to understand where things are and continually communicate this to management; operations and shared services are still wrestling with multiple disconnected tools. We are delivering faster, but are we delivering better? Delivering the right thing for the business goals? For the customer? More importantly, it doesn’t tell us if the software is actually meeting the needs of customers.
Software Delivery Management (SDM) truly changes the game by going beyond CI/CD and empowering developers and other stakeholders to best collaborate and creatively solve problems. It gives them the data, insights and best practices that allow them to truly continuously improve, keep value flowing and efficiently develop and deliver the right products and features to customers.
At CloudBees, we are right in the heart of this exciting new category. We’re extending the feedback loop to integrate the entire software lifecycle, starting with researching market demands and customer needs and then evaluating how software can be used to meet those needs, all the way from code through to customer support.
The Software Delivery Management strategy is all about recognizing software delivery as a core business process and any solution developed to support SDM needs a comprehensive management system. I previously outlined the four pillars of SDM that a solution needs to rest upon:
Our new CloudBees solution for SDM will help organizations facilitate collaboration between software development teams and other business stakeholders. You can expect our solution to include some of the most important capabilities that close the gap for software delivery.
Initially, our solution will be comprised of a platform to support SDM and will include modules for the product hub and value stream management. Future modules will become incorporated into the solution as it evolves. The CloudBees solution for SDM doesn’t replace our existing products such as CloudBees Core, CloudBees Flow and others. Instead, those products will become modules. Our customers can continue to evolve with us towards SDM as our solution for SDM unfolds.
I’m excited that our solution will support some of the most important needs of SDM now and in the future such as:
One unified system of record – With the CloudBees solution for SDM, information spread across multiple software planning, development and delivery tools can be captured, linked and cross-referenced The building of a single, unified system of record means everybody can see up-to-the-minute software delivery status via connected processes and get the information they need, when they need it.
While Software Delivery Management emerges as a market category, we want your voice to shape our solution. We’re also launching the CloudBees Solution for SDM Preview Program to ensure our solution meets the needs of organizations.
Using software to build business value isn’t just about delivering faster, it’s about creating software that appropriately addresses customer needs. Software Delivery Management is the only way to make sure the software your organization creates is meeting customer desires and building value for the business.
Learn how CloudBees makes software delivery management possible and visit our booth at DevOps World | Jenkins World. Download our new whitepaper on SDM — Continuous Everything: Why Software Delivery Management Matters.
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.
In a prior job as an engineering manager, I spent a lot of time identifying and trying to remove bottlenecks and inefficiencies that got in the way of value delivery. I wanted to give my team of creative, highly-trained developers the insights, data and processes automation to do their work as efficiently as possible, individually and as teams.
In practice, it was extremely frustrating. I often started my workday by manually sorting through information, alerts and statuses from the 10-20 of the most important tools of some total 40-50 different tools we were using. I was always trying to piece together a holistic view of where different features were in the value delivery lifecycle, where things might be stuck, but most importantly why. My daily goal of having a birds-eye view of everything in development was elusive. All the information was siloed and disconnected, and I couldn’t make sense of it manually, often resulting in unnoticed bottlenecks and inefficiencies that simply slowed us down, wasted time in forensic analysis…
The pipe dream was to one day gather and connect information from my software development and delivery toolchain to other parts of the business like our back-office business systems. Getting a complete view of the features in development was hard enough – understanding how those features are being used? Who is using them? Are the features being adopted? Are they driving business growth? Getting answers to questions like this was not something I considered possible in near real-time.
But now there’s a way.
Software Delivery Management (SDM) gives everyone in the software development and delivery organization, from developers to engineering managers, product managers to product marketers, doc writers, UI designers, support and business executives a way to easily see not just where product and features are sitting in the value delivery process, but also how the software is driving value. This is more than just extending the continuous integration/continuous delivery (CI/CD) process, but about extending the DevOps philosophy of collaboration and information sharing to the entire company. Just think. If you’re an engineering manager, here’s how software delivery management can transform the way you work, collaborate and connect with your development teams and your peers throughout the organization.
Without software addressing SDM, engineering teams rely on a diverse set of tools, each one designed for one step in the process. Getting a complete end to end view of value delivery across the different tools is a slow, manual process and the likelihood of unnoticed bottlenecks and inefficiencies getting in the way of value delivery is high. With CI/CD automation you may have gotten orders of magnitude faster at build/test automation and deploying code often.
But with Software Delivery Management, software, all artifacts and data from disparate tools used to move a product or feature from initial idea to max adoption are integrated into a unified common data layer, with the key information connected and easily accessible, giving each individual and team an unprecedented level of insight into bottlenecks and inefficiencies dramatically improving the speed at which better software gets to users safely.
Without software addressing SDM, there is no easy way for stakeholders to get an end-to-end view of the software development and delivery process and evaluate how well an application met its business objectives. The software organization, responsible for developing the capabilities to address business needs, lacks clear and continuous insights into the business drivers and specific customers’ needs. Once a capability has been delivered both the business stakeholders and the software organization lack true visibility into the adoption, outcomes and impact of the software. Without these insights, continuous improvement—and the resulting exceptional software quality – is impossible.
With Software Delivery Management, the continuous feedback loop established with CI/CD and DevOps is extended to fully include all stakeholders, from the ideation phase through user adoption and back to ideation. As usage data comes in, the application can be tweaked using feature flags and metrics-based testing of the software continuously while it’s in production. This allows developers to deploy software and features with specific groups before rolling it out in full production.
All of these things enable developers to better align the software with the business objective and improve the user experience. The result is software that’s not just delivered faster, but also better meets business objectives and customer needs, because even the best ideas are only ideas if they aren’t executed correctly. Instead of just delivering faster, Software Delivery Management helps teams deliver the right things.
Without Software Delivery Management, developers often don’t understand the purpose or the desired impact of what they are tasked to create. Business stakeholders often don’t have insight into what’s in development, how it will be implemented, when it will be delivered and how it drives impact. This is exaggerated by a lack of connected processes. Most organizations end up using massive spreadsheets, meetings, long email threads and Slack messages as a way to work around this—it’s what I used to do as an engineering manager. Yet the business still feels like development is a black hole, developers feel like they have no control, and nobody is really collaborating.
With Software Delivery Management, the silos between the software organization and other cross-functional stakeholders are broken down, so both can continuously understand what is needed, what is being delivered, and how it is driving business and customer impact. Information about the project is available to all stakeholders in real-time, in the form they need it. No more waiting for an email response or combing through a spreadsheet and hoping it has the relevant data. This makes it possible for the stakeholders to continually and seamlessly collaborate.
Software is ultimately made by creative, highly-skilled people who understand both the possibilities and the limits of software to solve business problems and create business opportunities. Software Delivery Management helps these individuals focus more on the creative problem-solving that software development requires by providing visibility, improving communication and eliminating disconnected teams and manual processes as much as possible. At the same time, the most creative solutions often come from cross-functional collaboration – and Software Delivery Management brings together not just different parts of the engineering department, like DevOps does, but facilitates collaboration between engineering and sales, marketing and/or other business units.
The goal of enterprise software development isn’t to create the software as fast as possible or to create the most technically sophisticated application. The goal is to use software as a tool to create business value and to create that value as quickly as possible. The ability to bring business strategy and software engineering together is critical to creating applications that are as effective as possible at meeting the business goals.
Wondering how Software Delivery Management can help you not just deliver software faster, but also create software that users love? Learn more about how CloudBees can help.
Register for DevOps World | Jenkins World 2019 to learn more about CloudBees and how SDM can play a role in your organization. Join the new CloudBees solution for SDM Preview Program.
Editor’s Note: This article is a first in a series of blogs about Software Delivery Management written by Shawn Ahmed, vice president of product marketing.
We truly live in exciting times … software has transformed every part of our existence. I remember the world just 20-30 years ago it seems so analog compared to now. The pace of innovation around us driven by software is sort of like the expansion principles of the universe, it’s scale and velocity is exponential and it’s become a part of every direction of my life. Clearly, it’s not slowing down any time soon either …
When I see a new incredible software-driven innovation, I remind myself that the teams behind it somehow managed to deliver amazing innovation, despite how difficult it actually is to do so. The bigger the development organization gets, the more teams you have working on different parts of the software. Teams may be working on completely different products and features across those products in different states of maturity and in different stages of value delivery. They’re grappling with complex architectures that span on-premises and cloud infrastructures or dealing with the daredevil nature of going completely cloud-native. Some teams are developing, some will be testing, some are operating the software. Let’s not forget to mention the people responsible for supporting the software and successfully implementing it in the market and all the people that work on researching and ensuring we are building things that actually matter. The product managers, doc writers, the designers and the product marketers to the people upstairs with C’s in their title worrying about the software keeping them competitive.
In a prior job, I remember coming into the office before anyone else arrived because, as an engineering manager, I struggled with collecting and getting a complete end-to-end view of my product and feature development activity across the SDLC. I’d start manually collecting data from development toolchains that seemed to exponentially grow and get more complex. Think more than 40-50 tools across the various teams, and of course, none of them shared anything…siloed and disconnected.
If you self-identify here, I am sure you will agree what a pain in the ass it is. Honestly, even with all that effort, most of the time I couldn’t identify the bottlenecks and inefficiencies that impacted (as my good friend Ben Williams would say) Delivery of Value. My teams were busy and all I wanted to do was to help them be more efficient.
Or maybe you identify with the developer that comes in the morning just trying to wrap their head around what they should focus on first? Digging around for clues and information in Jira, GitHub, Jenkins, etc. to get started. Or just trying to understand where and why their features are stuck across the software delivery value streams. Or when they are about to start building something new, just quickly being able to understand any previous work that has been done, any potential UI mocks, documentation outlines or POC architecture docs. Or how about you just want to know where your feature fits into the universe of value and who is using it and how. You just want to get feedback early and often on the features you’re developing.
Yeah … I know, I am just touching the tip of the iceberg of crazy. That’s why I am so pumped about the new category of software being dubbed Software Delivery Management (SDM). The sole purpose of this category of software is to unlock the true potential of software value delivery. The concepts and pillars of SDM were first introduced by Christina Noren in San Francisco months ago. The brainchild of industry luminaries like Sacha Labourey, Francois Dechery, Ben Williams and their amazing development organization tried to put some pillars into place to guide their efforts. Those pillars are:
Okay, so what’s in a category you may ask? Do you actually have any software in the category? Anything built that’s even remotely close to the guiding pillars? Any running code that can actually solve those pains and reach the Promised Land that presumably comes when you use software that supports SDM?
Short answer: YES!! We have been busy at CloudBees 🙂 And if you want to learn how CloudBees makes Software Delivery Management possible through its brand new software product called CloudBees SDM, come to DevOps World | Jenkins World in San Francisco August 12-15 and hear more about the unveiling of the product. We also have an early access Preview Program you can participate in, on the journey to software delivery value!
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.
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.
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:
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.
At the DevOps World | Jenkins World 2019 conference, CloudBees released an update to the continuous delivery (CD) platform it gained via its acquisition of Electric Cloud, signaling the company’s commitment to investing in a platform that’s employed widely in the enterprise.
CloudBees CEO Sacha Labourey said the rechristened CloudBees Flow builds on the application release orchestration (ARO) platform to further automate the last mile of a DevOps process.
Version 9.1 of CloudBees Flow provides a path to increased visibility into how a release is progressing, including the ability to view the inventory being deployed to a given environment and deeper insights into all the sub-pipelines that make up an overall release.
The latest release also provides more granular control over release pipeline execution, customizable dashboards within the platform’s Release Command Center and data archiving capabilities that make it easier to comply with regulatory mandates.
Labourey said that while companies that have developed commercial software-as-a-service (SaaS) applications tend to have very mature DevOps processes, most enterprise IT organizations are still defining the best DevOps practices they want to implement across their organization end to end. CloudBees Flow provides a continuous delivery framework for automating the deployment of applications at enterprise scale that complements the Jenkins continuous integration/continuous deployment (CI/CD) platform, he said.
Labourey noted the goal is to eventually unify continuous delivery processes across multiple platforms, including the ARO platform provided by Electric Flow, the Jenkins CI/CD platform and the Jenkins X and Spinnaker platforms that are optimized for building and deploying microservices-based applications on top of Kubernetes. As part of that effort, earlier this year CloudBees became a founding member of the Continuous Delivery Foundation (CDF), an arm of The Linux Foundation dedicated to foster best continuous delivery practices.
Most organizations that have adopted CI/CD platforms have seen varying degrees of success in taking advantage of continuous integration to accelerate the development of their applications. Continuous delivery, however, has proven to be a much bigger challenge. Organizations tend to struggle with everything from making sure they have the appropriate infrastructure resources available to support a new release of an application to debugging application code before and after it’s deployed in a production environment.
It may be a while before most enterprise organizations truly master DevOps processes end to end. However, given how dependent on software most organizations are, increased reliance on DevOps processes has become a prerequisite for any form of digital business transformation. As the volume of software being developed increases, the rate at which updates to applications are being made also increases substantially. Most organizations are not going to be able to keep pace with that rate of change by relying on legacy software development and deployment processes.
In many more cases now, however, the challenge organizations are wrestling with is not so much whether to transition to DevOps, but rather determining which DevOps processes to standardize on to satisfy the elevated expectations of business leaders anxious to provide customers with that next great application experience.
At the DevOps World | Jenkins World 2019 conference, CloudBees announced that the latest version of its CloudBees Accelerator platform now supports cloud bursting to all three of the major public cloud service providers.
CloudBees Accelerator makes it possible to distribute the build, quality assurance and testing cycles across a large cluster of inexpensive servers. Version 11.1 further extends that capability into the public cloud by adding support for Microsoft Azure and Google Cloud Platform, alongside existing support for Amazon Web Services (AWS).
Company CEO Sacha Labourey said as organizations embrace multiple clouds for application development and deployment, continuous integration/continuous deployment (CI/CD) platforms will need to span hybrid cloud computing environments. Most organizations are not yet making use of multiple public clouds to develop an application, but they are increasingly relying on external cloud resources to augment the infrastructure resources they have available in on-premises IT environments.
In addition to providing cloud bursting support for Azure and GCP, version 11.1 of CloudBees Accelerator provides support for Android Q, a forthcoming update to the widely employed mobile operating system due out in the third quarter of this year. Other new capabilities include support for the SSL and TLS cryptographic protocols and improvements to out-of-the-box support for Windows, including the ability to distribute and cache Visual Studio projects.
Version 11.1 of CloudBees Accelerator also now makes it possible to apply CloudBees Electrify, a framework for optimizing the use of all available infrastructure in parallel, to accelerate build tools such as MSBuild and Scons. In addition, it provides improvements for the open source Yocto Project, an initiative from the Linux Foundation that streamlines the creation of Linux distributions for embedded systems. CloudBees Accelerator enables developers to at least triple the speeds of builds using BitBake build tools or Buildroot files and patches.
As expansion occurs in both the volume and types of applications that organizations rely on to build and deploy faster, the need to rely more on automation also is increasing. Many DevOps processes that organizations adopt initially have been crafted manually. As organizations become more adept, however, it becomes apparent there is an opportunity to automate a wide range of lower-level processes. Frameworks such as CloudBees Accelerator essentially provide a layer of abstraction that enables organizations to devote more time and energy to writing application code.
In fact, the next wave of organizations adopting DevOps is likely to benefit greatly from all the processes that the first wave of adopters helped automate by identifying best DevOps practices. It remains to seen just how automated the entire CI/CD environment can become with the rise of, for example, artificial intelligence (AI), but with each passing upgrade cycle, the accessibility of DevOps increases thanks primarily to advances in automation. Those advances not only make it easier to share best DevOps practices across an enterprise, but they also make it feasible for more organizations to embrace DevOps because the level of expertise required to master those DevOps processes declines.
The clock is ticking. DevOps World | Jenkins World, the world’s biggest annual gathering of Jenkins users and DevOps practitioners, is just around the corner, scheduled for August 12-15 in San Francisco. The agenda is set. The DevOps Community is rolling out the red carpet. Are you coming?
You’ll be among the largest gathering of DevOps superheroes. We’re also pulling out all the stops, offering more speaker sessions, a bigger expo set-up and a themed superhero after-party for conference-goers to let loose at, following a full day of activities.
Located in the heart of Silicon Valley, the city of San Francisco itself is a world-class conference draw. We’re looking forward to sharing a few days with a record 2,000 attendees in just a few short weeks.
This year’s theme is “Transform and Deliver,” and the conference will deliver on a number of fronts. It will entertain, educate and maybe even surprise attendees with the wide array of offerings planned for the four-day time frame. It also will focus on the concept of delivering software–highlighting the value digital transformation has in delivering software more efficiently, more quickly and with higher quality.
Whether you are already prepping for the show or still considering a trip, here are a few of the things on tap for this year’s event.
At DevOps World | Jenkins World 2019, you’ll find plenty of opportunities to learn and engage at every turn. This year’s San Francisco event will feature more than 100 sessions covering a wide range of DevOps-, software delivery- and Jenkins-related topics. In San Francisco, sessions will be conducted by practitioners from organizations such as: Adobe, CloudBees, Eli Lilly, Fugue, Google, IBM, Latam Airlines, Liberty Mutual, Microsoft, Salesforce, SAP Labs and The Hartford.
Let’s talk specifics. This year, attendees can learn about everything from cloud native and Kubernetes to pipeline development and management, CI/CD, release management, data and reporting, DevOps and security/compliance. Highlights include From Zero to DevOps Superhero: The Container Edition, with Jessica Dean of Microsoft; Continuous Delivery Directly to the Car, with Rafal Kowalski of Grape Up; 10 Attributes of the DevSecOps Elite with Derek Weeks of Sonatype and Hasan Yasar of Carnegie Mellon Software Engineering Institute.
The conference will feature a series of keynote addresses, as well. Speakers will include CloudBees CEO Sacha Labourey, Jenkins Founder Kohsuke Kawaguchi, CloudBees VP of Marketing Shawn Ahmed, CloudBees VP of Product Management Ben Williams, CloudBees CMO Andre Pino, Google Cloud Developer Advocate Dave Stanke, Redmonk Co-founder James Governor, CloudBees Director of Open Source Community Tracy Miranda, Cloud Native Computing Foundation CTO/COO Chris Aniszczyk, Jenkins X Co-creator James Strachan, Netflix Director of Delivery Engineering Andy Glover and Google Cloud Platform Engineering Manager Tara Hernandez.
If the training and workshops–held on the conference’s first two days–help provide the skills needed to help your organization transform to DevOps, the final two days (August 12-13) offer up a wide variety of sessions from experts that will enable you to deliver success.
Training topics will include Continuous Delivery with Jenkins X, DevSecOps Engineering Certification, DevOps Leader Certification, Jenkins Admin Fundamentals, CloudBees Core Fundamentals and Continuous Delivery with Jenkins on Google Kubernetes Engine. All trainings and workshops are available to add onto the full conference sessions pass for an additional cost.
Attendees registering for the conference will receive a free Jenkins certification exam voucher ($150 value) for the Certified Jenkins Engineer (CJE) or Certified CloudBees Jenkins Platform Engineer (CCJPE) exams. You can choose to sign up for an on-site exam at DevOps World Jenkins World (first come, first served) or use it at a later date. There are also several half-days, one- and two-day courses that can be added during the event registration process to help attendees prepare for certification.
Beyond the official sessions, there will be ample time to network with colleagues and check out the latest and greatest from industry vendors on the expo floor. Exhibitors include DevOps World’s showcase sponsor Google, premium sponsors Sonatype and VMware, and other sponsors such as GitKraken, Gradle, Honeycomb, Incredibuild, Mattermost, Instana, OverOps, Scalyr and Zebrium.
The DevOps World | Jenkins World 2019 Awards recognize the achievements of DevOps innovators and Jenkins practitioners around the globe, with two categories of awards announced during the conference: The Jenkins Community Awards, celebrating individual Jenkins community contributors, and the CloudBees Innovation Awards, honoring companies that demonstrate quantifiable business value from DevOps, CI and CD using CloudBees solutions.
Jenkins awards include honors such as Jenkins Security MVP, Most Valuable Jenkins Advocate and Most Innovative Jenkins X Implementation. CloudBees Innovation Awards include the DevOps Automation Excellence Award, the DevOps Scalability Achievement Award and DevOps Rising Star Award.
Everyone who attends DevOps World | Jenkins World is a DevOps superhero. On the Wednesday night of the conference, grab your capes and masks to celebrate with the industry. Join us for our superhero-themed party!
Are you ready for this year’s show?
Learn more about DevOps World | Jenkins World. Then register and use code DWJW20 to get a 20% discount off your registration.