devopsy.kinsta.cloud

Tag: CD pipeline

Get Testing Bottlenecks Out of Your Pipelines

I first learned the term “deployment pipeline” when I read “Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation,” by Jez Humble and David Farley back in 2009. End-to-end automation of the build, deploy, test and release processes kick in each time a team member commits a change to the source code repository.

Chapter 5 of the book notes that the forms of testing common to all projects include manual test stages which “… assert that the system is usable and fulfills its requirements, detect any defects not caught by automated tests, and verify that it provides value to its users. These stages might typically include exploratory testing environments, integration environments, and UAT (user acceptance testing).”

Humble and Farley include these manual stages in the deployment pipeline, also known as a continuous integration (CI) pipeline, build pipeline or delivery pipeline. However, from what I observe, I think a lot of times people forget about these important manual stages.

Though we can do more and more with test automation, thanks to improving technology, manual testing activities are here to stay in most business domains. My own previous team realized this as we started to move toward continuous delivery (CD) a couple of years back, with twice-weekly deploys to production. Smaller changes and more frequent deploys means lower risk of regression failures. Yet, we still struggled with how to fit in important manual testing activities.

Whenever my cross-functional delivery team has a problem, I look for a way to make it visible, to help us talk about it and brainstorm ideas to solve it. My “aha” moment around manual stages came when I learned techniques to visualize our pipeline from Abby Bangser and Ashley Hunsberger. My team knew we had these manual testing activities and that we wouldn’t feel confident about releasing changes without them, but we weren’t really thinking about them as stages in the pipeline.

Visualizing Your Pipeline – Including the Manual Stages

Figure 1: A Continuous Delivery Pipeline (my diagrams are inspired by Katrina Clokie’s pipeline diagrams in “A Practical Guide to Testing in DevOps”)

Getting your team together to visualize your pipeline is a great method to find ways to improve it. Gather around a table with cards or sticky notes, or draw on a whiteboard—what are all the steps in your pipeline, including the manual ones? In Figure 1, the manual stages in a team’s CD pipeline are shown in yellow. All the automated and manual things need to happen before the business decides to push the button and deploy to production. It’s easy to see that these manual stages can become a bottleneck. Manual exploratory testing is likely to take longer than the automated test suites. If user acceptance testing needs to be done by certain business stakeholders and they aren’t available at the right time, that holds up the release. If the team is looking to move to continuous deployment, where every change to the product goes out to production as soon as all stages complete successfully, these manual stages will be in the way.

When you get your whole team including developers, database experts, operations specialists and product owners involved in solving these problems, you may discover innovative ways to approach them. In my team’s case, we decided everyone on the team needed to help with exploratory testing so we could do it in a timely manner. Testers helped the developers learn exploratory testing skills with hands-on workshops and by pairing with them. Then, each developer pair working on a story was tasked with doing the exploratory testing at the story level before declaring the story finished. We wrote exploratory testing charters at the epic or feature level as stories in our backlog. When enough stories were complete, anyone on the team, including testers and product owners, could pick up those charters.

If we couldn’t complete all the necessary exploratory testing before the next production deploy, we used feature flags to hide the changes from customers until we could complete the testing. We could go ahead and deploy the changes and wait to release them once we felt confident they would not cause any customer pain.

Asynchronous Testing Stages

Using feature flags or toggles is a good way to allow the team to approach some manual testing activities asynchronously, so they don’t hold up the deployment pipeline. If some required manual accessibility, testing takes an extra day to complete or the UAT has to be postponed for a week, the deploy still happens. A change could be toggled on for a small percentage of users and observed in production to see if any unexpected behavior occurs. Whatever activities are needed to safely release a particular change don’t have to hold up other changes that are ready for customer use.

Figure 2: Asynchronous stages in a deployment pipeline

Figure 2 is an example of a continuous deployment pipeline, but this asynchronous approach to the manual stages works for continuous delivery as well. Each time a team member commits a change, if all the automated stages in the pipeline pass, the release candidate build will be deployed to production. The manual testing activities are not inline with the other steps and don’t hold back the deployment.

If we’re ready to deploy a feature but need to finish those manual testing stages before we release it, developers can put in a feature flag set to “off” to prevent it from being exposed to customers. When the asynchronous manual stages are all complete and successful, the feature flag can be flipped on in production. This is the actual release, customers can now use the feature. The feature flag should be removed as soon as possible, as too many feature flags at once has serious risks.

Using feature flags or toggles to permit deploying changes to production before all testing stages are finished is one way to avoid bottlenecks and succeed with continuous delivery or deployment. Continuous delivery and deployment success depend on doing frequent small changes, not big-bang releases. A lean approach to feature flags, keeping the inventory low, is advisable.

Visualize It With Your Team

We’ve looked at one way to keep manual pipeline stages from holding up deploys, but there may be other solutions for your team. And there are lots of other key success factors for CD, such as keeping changes small and frequent. There’s lots to discuss and brainstorm about as your team, or a representational cross-section of it, gets together and experiments with a visual model of your pipeline. Talk about what you need to learn from each pipeline stage, who needs to know it and whether the pipeline is providing actionable feedback.

As a tester, I’ve sometimes questioned aspects of the pipeline that nobody else had thought about. Having team members with development, operations, database and other skills present means more potential for creative solutions. Our pipeline provides a major feedback loop and we want that feedback as fast as we can get it. Writing each stage on a card and arranging them on a table or wall often triggers ideas for parallelizing more stages or realizing a particular stage isn’t necessary or can be done locally by developers.

Automate all the things where it’s feasible. Use the time you save to optimize the way you accomplish manual testing activities and possibly automate more of them. Master techniques such as feature flagging so that you can take the time needed to feel confident about every new feature you release.

References

“Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation,” Jez Humble and David Farley, https://continuousdelivery.com

“A Practical Guide to Testing in DevOps,” Katrina Clokie, https://leanpub.com/testingindevops

“Feature Toggles, AKA Feature Flags,” Pete Hodsgon, https://martinfowler.com/articles/feature-toggles.html

— Lisa Crispin

May 24, 2019
5 Guaranteed Ways to Kill DevOps Developer Productivity

“A developer is an organism that turns coffee into code.” I still laugh when I see that quote as it reminds me of my hardcore developer days, when my cube always seemed to be directly next to the coffee machine and caffeine was management’s way of ensuring we had the energy to develop well into the wee hours of the evening.

What is developer happiness? I like to believe it hasn’t changed dramatically over the years. It’s about giving developers the right tools and the freedom to do what they do best—produce meaningful code. That means reducing distractions so they can meet or beat expectations and timelines, ultimately driving revenue for the organization.

I trust your company is not in the practice of molding reusable human coffee filters. But are you doing everything you can to help your developers be as satisfied and productive as possible, or are you taking the “necessary” steps to ensure they are buried in context-switching hell?

If the latter is your aim, read on to learn about five guaranteed ways you can totally kill developer productivity.

Saddling Developers With ‘Plumbing’ Work

Companies frequently look at developers primarily as technical resources instead of true innovators, so they get saddled with plumbing work. In DevOps and continuous delivery (CD), that’s writing a lot of ad-hoc scripts to string together pipelines, define infrastructure and manually create deployment plans. If your company is on the road to cloud adoption, it’s imperative to get unnecessary scripting under control because things only get more complicated as you start to incorporate the many different cloud platforms and services that are available.

Making Developers Deal With Security After the Fact

A fail-safe way to kill developer productivity is to make them deal with security after a release has left development. Too often, they first build code, QA then tests it and finally someone from security checks it to make sure there are no holes well after the code has been written. If security problems are found after coding is done, the release is halted and must go back to the developer to fix. This often occurs either just before the production release or, worst case, just after. In either case, not only does it take longer to resolve the problem, it also prevents the developer from moving on to the next big thing.

Expecting Them to Chase Down Features and Status Requests

Because development pipelines are often not integrated with the higher-level CD pipeline, those outside of development have no way of seeing the status of features, deployments and releases. Understandably, their only option is to ask developers to provide status information or call a status meeting which, of course, are additional interruptions that divert them from feature development. Developers don’t like it, and it doesn’t exactly help anyone else in the pipeline be more productive, either.

Bogging Developers Down With GUIs

GUIs are a great democratizer in large organizations. They offer a user-friendly way for people across the company, regardless of technical know-how, to access the information they need to be productive. But many developers see them as a waste of time. And while even the most GUI-resistant developer needs them every so often, they are not their preferred way to work.

Taking Away Their Favorite Tools

Standardizing your software delivery process is a must to increase efficiency, but standardizing on tools is not. Taking away their favorite tools is highly recommended only if you’re keen on decreasing developer satisfaction.

What are the Alternatives?

Managers and leaders can help developers by taking as much of these mind-numbing tasks off their plates as possible. They can do that by automating the release process and integrating CI pipelines into the CD pipeline. Doing so allows everyone to plug in to what’s happening in development without having to interrupt developers, and they can continue to use their beloved tools and simply connect them into the release pipelines.

It’s also important to standardize most of your operations work upfront—infrastructure, provisioning, compliance, security. All this advance work will allow developers to consume environments on-demand and just deploy without extensive scripting or re-scripting for changes and maintenance.

Keep in mind, if you shift security left, closer to the development process, you need to automate it. Otherwise, it becomes someone’s manual task—a developer, DevOps engineer or security person—and that will slow down the delivery process. For example, SAST test and SCA scans can be automatically run on every check-in. DAST tests can be automated to run after each build. This way, any security holes are caught as early as possible, while the code is still fresh in the developer’s head.

Finally, reduce the amount of work developers need to do through GUIs. Give them a way to kick off releases from their respective CI pipelines and the ability to define release pipelines—infrastructure, configuration, security and so on—in code.

Coffee Machine or Barista?

Doing these five things—relieving developers of unnecessary scripting, standardizing compliance requirements and security checks upfront, reducing the need for developer-provided status updates, enabling them to work in code and allowing them to continue to use their favorite tools—will make the difference in whether your developers feel like the office coffee machine or a master barista.

— Dan Beauregard

May 10, 2019
‘DevOoops’ Moves: Deploying Code Out of Step
‘Everything as code’ can create opportunities for misadventure for DevOps teams

DevOps’ ultimate aim is to create efficiencies in the software delivery process. But it doesn’t always work out that way. Sometimes DevOps initiatives lead to mistakes—something we lovingly call “DevOoops.” CloudBees recently polled some colleagues and came up with five examples of a DevOoops in action. Following is a discussion submitted by Director of Engineering Laura Frank Tacho about deploying code out of step.

Scenario:

Running in parallel during CI/CD can speed up your automated testing and shorten your feedback cycles. Just make sure deployment is not executing as a parallel step. That misconfiguration will cause your code to deploy at the same time the tests are running, regardless of their exit codes, pretty much defeating the purpose of automated testing before a deploy.

This scenario touches on a theme we’ve seen throughout most of the “DevOoops” stories our colleagues have come up with. The theme is how the emerging concept of “everything as code” can create opportunities for DevOps teams to slip on proverbial banana peels.

In this case, we’re talking about sequencing problems in a process we can call pipeline as code.

To be successful, teams need to extend a quality-first approach in automated testing throughout their continuous delivery life cycle—from code to commit to test, as well as through the various tiers of the development life cycle. And with a quality-first approach, you need to apply testing and quality management to your environment configurations and infrastructure as code.

Laura’s example highlights how teams need to treat their CD pipelines as applications themselves. They need to check for and eliminate bugs and errors in CD pipeline code to ensure that code is operating as expected. Failure to properly manage the creation and evolution of complex CD delivery pipelines will result in significant cost or risk.

So, if you don’t have proper test coverage on application code, you could end up releasing an application that hasn’t been tested at all. If the app doesn’t pass through a security gate, as it’s supposed to, you could release unintended preproduction data.

While there are always risks with untested code, we have to give unique consideration to untested or unmanaged CD pipelines. We need to consider the risks of what missed gates could mean for our developers, our organization and our customers.

Teams should do the following as they release their CD pipelines:
- Build: Start from the left-hand side of process and work through the defining and coding of CD pipeline left to right in the direction your apps and development artifacts flow: from dev to test to deployment. While we may not be able to define an ideal automation solution completely on the first pass, going left to right encourages teams to focus on what the life cycle of an artifact looks like.
- Manage: Define your CD pipeline using an everything-as-code or pipeline-as-code approach. For this to add value, you must manage development of your CD pipeline as you would your application code and apply software best practices. Check your CD pipeline code into a source code repository and leverage language-specific technologies that can check your syntax. (If you’re using Groovy-based code or Jenkins-based code, there are versions of Lint that can perform these functions.)
- Create staging environments: You should establish staging environments or test pipelines to validate your CD process. These pipelines should go through all checks and gates against your real tools, using reference code that is representative of the applications your pipeline would be servicing but stops short of production into environments.
This will give you an opportunity to iterate changes against your application code, do some initial scans and checks to collaborate to define your CD pipeline in code-managing SCM. Execute initial validation on scans as pipeline as code and then validate expected operations in a staging environment before you deploy it as the basis of the pipeline for your production of business-critical applications.

Key Takeaways
- This story highlights how crucial it is to ensure that your application code and environments pass through certain gates and checks before being deployed out to the customer.
- You need to construct your CD pipelines so your parallel testing is managed as a gate to production, ensuring that properly tested and validated changes are not automatically deployed.
- Deployment happens at the end of all the processes within a pipeline, and all required tests, validations, checks and approvals have been done before any change is deployed to the customer.
To read our previous “DevOoops Moves” post, click here.

— Brian Dawson
May 7, 2019
DevOps Chat: BlueOcean Puts CD Pipelines Within Reach of Every Team
Blue Ocean brings easy-to-use continuous delivery for teams to everyone. Years in the making, Blue Ocean is a major project built from the ground up for Jenkins Pipeline. I had a chance to speak with two of the key contributors from CloudBees and the Jenkins community, James Dumay and R. Tyler Croy. Tyler is on the Governance Board for Jenkins.

Blue Ocean provides:
- Sophisticated visualizations of CD pipelines, allowing for fast and intuitive comprehension of pipeline’s status.
- Pipeline editor makes creation of pipelines approachable by guiding the user through an intuitive and visual process to create a pipeline.
- Personalization to suit the role-based needs of each member of the team.
- Pinpoint precision when intervention is needed and/or issues arise. Blue Ocean shows where in the pipeline attention is needed, facilitating exception handling and increasing productivity.
- Native integration for branch and pull requests enables maximum developer productivity when collaborating on code with others in GitHub and Bitbucket.
As usual our conversation in the streaming media player is immediately below.

Streaming Audio

Transcript of our conversation

Alan Shimel: Hey everyone. This is Alan Shimel, editor in chief of devopsy.kinsta.cloud. Welcome to another DevOps Chat. We have two guests today on DevOps Chat. We have James Dumay and R. Tyler Croy of the Jenkins community. James, Tyler, welcome to DevOps Chat.

James Dumay: Nice to be here, Alan.

R. Tyler Croy: Thanks for having us.

Shimel: Thank you. Let’s start off though with just a little background of each of you. James, you’re coming to us all the way from Australia. In deference to the distance, we’re going to let you go first. Why don’t you share with our audience a little bit of your background?

Dumay: Yeah, sure thing. So I’ve been probably building development tools for the last 10 years. I think I’ve found my calling here. I love making developers more productive. I also want to make developers happier. So I do have this bee in my bonnet that developer tools are difficult when they’re boring and they’re not very pleasing. It’s my life’s mission to turn that around.

Shimel: Excellent. Tyler, how about you?

Croy: I’ve been with the Jenkins project a little over eight years now. I started using it when I was a back-end services engineer, a few startups ago. Every single company that I’ve joined needs more continuous delivery or some non-zero amount of continuous delivery stuff. So I found myself getting more and more ingrained in the Jenkins project and bringing Jenkins to bear in companies to ship products faster. Now I work at CloudBees talking about how you can do that and help other people see the light with some of the Jenkins stuff I’ve been doing for a while.

Shimel: Tyler, I don’t want to embarrass you. You actually are—I don’t even know the word, but you’re one of the—on the steering committee or the governing committee for Jenkins. Is that the right way to put it?

Croy: I guess you would say I’m on the Jenkins governance board. In the beginning of the Jenkins project, there was Kohsuke Kawaguchi who was the founder of the project, and then there are a few other core folks that were floating around that helped get Jenkins off the ground. Andrew Bayer who is a major contributor to the pipeline toolset, is one of those people. So I’ve just—Jenkins became a really important part of my life. I started spending a hell of a lot more time with Jenkins, and now I’m one of the people that makes sure that the project continues to move forward.

Shimel: Excellent. James, I don’t know if you mentioned your role other—at this point, other than you’re cuckoo for Jenkins. What exactly is your role right now?

Dumay: I’m director of Product Management at CloudBees, but I’m also a community leader for the Blue Ocean project. I do all the outreach and talk to all the users. It’s good fun, but previously before I was at CloudBees, I was at a small Australian startup called Canva. They do an online design tool. Prior to that, I spent seven years at Atlassian, where I was product manager for actually a competing product.

Shimel: Absolutely. Well, we’re allowed to have competing products. They may not be any good. I’m only kidding. James, you mentioned the magic word. You get the first prize today. That was Blue Ocean. Today’s a bit of a—more than a bit—today is a big day in the Jenkins community. This release has been highly anticipated. It’s been in beta and in testing, alpha before that for some time. Talk to us. What about it? Why should people care?

Dumay: All right. That’s a big question. So I guess we’re living in a really interesting time in the industry. We have this—there’s this ride of exponential change that is happening across our industry, whether it’s tooling and technology and process, or just the raw number of people writing computer software in the—we’ll be in the year 2020 soon. I think if you look back in the previous 10–20 years, the amount of companies out there that are writing software today and were not writing software 10 or 20 years ago. So Marc Andreessen speaks about software eating the world, where all the value that companies provide slowly but surely are being made, not by the engine in a Ford motor vehicle, but it’s the software on board the Ford motor vehicle.

So it’s an interesting time to be a software developer, or to be in this field, but it’s also a really interesting time to be a tools creator. I think with this increase of people in the industry—it’s not like we have lowered the bar to what we call a software developer, but I think there’s a lot more people today who, in their jobs, whether it be financial services, or in other industries, who are finding their job involves writing software. I think there’s a big challenge here, and Blue Ocean is founded on going out there and solving this problem, that how do we make the millions of software developers or even people who are just writing software as part of their jobs, how do we make them more productive? How do we make sure they can get what they need to get done as quick as they can get it done at the highest quality that they can get it done with the best tools possible?

So with Blue Ocean, we’re sort of focused in on the practice of DevOps and on continuous delivery. We set ourselves a goal. What if we can make it really easy for people to adopt continuous delivery? Blue Ocean is our answer to that.

Shimel: Tyler, James—I think James made some important points. What can you add there? Why—let’s step back a second. Let’s say our audience is vaguely familiar with Jenkins. Most of them probably use it, but there’s some maybe that don’t. What is—let’s start with what is Jenkins to them? What does Blue Ocean represent to Jenkins?

Croy: Sort of at a high level, Jenkins is an automation server. Jenkins is probably the most well-known tool of its kind across the entire software industry. As far as helping developers build and test and deploy their software, chances are with most organization today, if someone doesn’t think they’re running Jenkins, they might just not be aware, or they might be so far removed, or that it’s hiding, that they don’t know that it’s actually there. It’s pretty omnipresent in the industry right now.

One of the big things about I would say the shift in the industry that has made Blue Ocean important—when I first started in northern California about 10 or— [inaudible] 10 years ago, continuous integration was this really big, important thing. I kept coming to companies who either didn’t have a continuous integration server, or didn’t practice—nobody but the developers knew that there was a continuous integration server. As the industry has shifted towards this more and more rapid pace of “Let’s practice continuous delivery. Let’s get product and value to our customers as soon as possible,” it’s no longer acceptable for just the developers to get feedback to what’s going on in that process.

So I think the important thing for Blue Ocean, and I would say broader software industry, is that continuous delivery is not a developer thing. It’s an entire team thing. It’s an organizational thing. Blue Ocean is designed from the ground up to make sure that people who might not be writing code every single day, or they might be designers, or they might be product managers, or stakeholders of some form or fashion in the software development process. They need to know what’s going on and Blue Ocean is going to give them a window into what’s going on in the delivery pipeline. That’s a pretty dramatic shift from the Jenkins that was created 10 years ago, which was just for developers.

Shimel: Got it. Got it. Now guys, I’ve had the—I don’t know if the word is a pleasure, but I’ve had the—well, it was a pleasure in a lot of ways, but I’ve had the experience of being involved with open-source projects in the past. It’s a fickle thing being part of a community. It’s even harder when you have a corporate entity such as CloudBees in this—CloudBees isn’t alone in this. There are many companies that are mentoring, managing—whatever you want to call it—open-source projects. Talk—I loved what I saw of how that relationship was handled as it applied to Blue Ocean.

Guys, can you give us a little color on that? No pun intended with Blue Ocean and color, but a little background on how you worked with the community to deliver, I think, what the community consensus was what was needed.

Dumay: Just to preface this. So this is my first time working full-time on behalf of the commercial entity for _____ community. So I—when we started at Blue Ocean, I kind of put myself in Tyler’s very capable hands. Tyler had had a lot of previous experience, not with Jenkins, but with other projects, walking that fine line between community and the need for the business sponsor, I guess. So it’s been an interesting process. I think certainly for CloudBees, a healthy Jenkins community is a healthy CloudBees, and a healthy CloudBees is a healthy Jenkins community. It all feeds into each other. As long as, I think, we take things from a project perspective, like what’s good for Jenkins, we’re making good decisions in both aspects.

Certainly, we had been running—more in terms of Blue Ocean itself, we had been running for multiple years Jenkins community surveys, and one of the top issues people would have liked to see addressed in that feedback had been the user experience with Jenkins. They really wanted it to be easier to get started. They really wanted clarity when they’re looking for particular cases, information. I think there was a real groundswell there to see some improvements, and see some sort of more modern thinking around how to solve problems. I hope that we’ve done that. Certainly the feedback that we’ve been getting from the community has been pretty great.

Just on the community itself, I think software developers can be a pretty passionate tribe of people. So it’s—the Jenkins project is no different from the wider developer community. They’ve been passionate in a very encouraging way, in a very forgiving way as well. Particularly when you go ahead and think about any product that has—web product that has been redesigned. So the people get very upset. They’re very invested in the tools that they use, or the products that they use, and then you move their cheese, and people go “Where did that thing go? Where did this other thing go? No. I was using that. Bring it back.” I think with the Jenkins community, I think they’ve been very—I think they’ve wanted the change for so long that as things change, we—they’re getting some new goodies in their bag and they’re happy to let some of the old bits disappear.

Croy: I think there’s also—if you look at that feedback from the Jenkins user list going back years and years and years, there’s been—most people, I would say, that contribute to the Jenkins project, note they’re new, I guess past tense, because Blue Ocean is one meadow now—knew that something needed to get fixed, and someone needed to do something to really improve and set up Jenkins for the next 10 years. The skill set and the passion and the vision really wasn’t there.

So when James and his team, his colleague Michael Neale and some of the other people, really started to get involved, I think it was easier for other contributors in the project to rally around that. It was clear that not only did they know what they were doing, but they understood the challenge in that we needed to think about the design from the ground up, as opposed to reskinning or reseaming Jenkins. They needed to evaluate it from a user experience standpoint and start from 2016 rather than 2006, which is when the project really started. So I think that was really helpful to have some—a passionate group of people with vision to drive it forward.

Shimel: A passionate group of people with vision can accomplish a lot. That’s for sure. Guys, let me ask you—we’re almost out of time. What—for each of you, and we’ll go with James first. James, what do you think is the single biggest aspect or feature of Blue Ocean that our listeners should take a look at?

Dumay: That’s very unfair, Alan. I love them all.

Shimel: How can a parent decide? But guys, so pick one. Doesn’t have to be your favorite or biggest, but one that we’d like to call out.

Dumay: The official pipeline editor. So _____ delivery pipeline is difficult at the best of times for people to create. So we set ourselves a challenge. What if we could make it very easy for people to create a continuous delivery pipeline using Blue Ocean UI. The one thing I really like about it is it really is for everyone. We talk a lot about—we’ve got a lot of plans for the Blue Ocean in the future. One thing we talk about is the Fisher Price’ing of the editor. I don’t know if you’re familiar with Duplo blocks you give a toddler. But you can get all these different attachments, all these crazy things, and you can customize your own creation using Duplo. It’s non-checkable Lego. So really, Duplo is for everybody. So anybody of any age can—of any skillset, can construct something from Duplo.

The thing that I like about the—I guess the vision behind the editor is anybody can construct a continuous delivery pipeline, even if they don’t have coding knowledge. Maybe they want to take—they have—we can go as far as they can have a PHP website on a Dropbox folder and they want to upload that, deploy that continuously to their webhost, their DreamHost or something like that. That’s the kind of—we want to bring continuous delivery to everyone.

I think the communal pipeline editor is the vehicle to do that. One of the great things about the editor as well is that it is what you see is what you get. So when you build it in the editor, that’s exactly how you visualize it later on in Blue Ocean, as that pipeline is executing. It’s really powerful in that way.

Shimel: Great. Makes sense. Tyler, how about you?

Croy: So my interactions with Jenkins are typically when something goes wrong. I think that’s maybe a bit more common for an infrastructure administer or developer. So, for me, I would say the No. 1 killer feature with Jenkins—with Blue Ocean and Jenkins is that the clicks to get from a failure or something going wrong to seeing what actually went wrong, it’s pretty much one click. So the visualization of status is so much faster and more immediate in Blue Ocean that when I come to Blue Ocean to figure out what test failed, or what went wrong in my pipeline, I get that in a matter of seconds, as opposed to drilling around and hunting through console help. So for me, that’s probably the killer feature.

Shimel: Make sense. Guys, we’re going to wrap up here in a moment, but just quickly, for people who want to find out more about Blue Ocean, where can they go? James, Tyler?

Dumay: No problem. They can go over to Jenkins.io/projects/blueocean or the Jenkins blog, which is Jenkins.io/blog.

Shimel: Okay, Tyler, I’m going to hit you with the last question. Now that Blue Ocean is 1.0, what’s next?

Croy: [laughter]

Shimel: [laughter] You didn’t expect to get a rest, did you?

Croy: No, no. I think the really important thing that’s next for the Jenkins project is I would say the next three months of Jenkins pipeline and Blue Ocean adoption. Now that we’ve got the tools that we’ve brought to the broader software industry for building and constructing and running continuous delivery pipelines, we’re going to need to iterate, on them and we’re going to need to make them better as more and more people start to adopt continuous delivery. I think we’re, certainly before the end of the year, we’re certainly going to find new things that we can add into Jenkins to make that an even more enjoyable experience.

Shimel: Absolutely. Hey guys, congratulations. I know it’s easy on release day to say something came out. There was a lot of work here, an awful lot.

Croy: Indeed.

Dumay: Very much so. Thanks.

Shimel: Thank you, James, Tyler, great job. R. Tyler Croy, James Dumay of CloudBees and Jenkins talking about Blue Ocean, the big news around Jenkins and CICD Pipelines. Guys, thanks very much. Hopefully we’ll have you back soon on another DevOps chat.

Croy: Thanks a lot. See you later.

Dumay: Thanks.

Shimel: This is Alan Shimel with DevOps Chat. We’ll see everyone soon on another DevOps chat, but until then, have a great day.

— Alan Shimel
May 2, 2017