Tag: development tools

  • Microsoft Adds Slew of Developer Tools to Azure

    Microsoft Adds Slew of Developer Tools to Azure

    At its Build 2023 conference this week, Microsoft announced general availability of an Azure Deployment Environment service that provides developers with a portal through which they can employ infrastructure-as-a-code (IaC) templates based on Terraform or Azure Resource Management files.

    In addition, Microsoft has enhanced Microsoft Dev Box, a workstation environment for developers that run Azure, to include a portal through which they can manage multiple environments.

    Scheduled to be generally available in July, Microsoft Dev Box is also previewing a capability that makes it possible to customize environments using configuration-as-code files stored in a Git repository. Microsoft is also previewing tighter integration between Dev Box and its Visual Studio integrated development environment (IDE) and Windows to further customize developers’ environments.

    Scott Guthrie, executive vice president of the cloud and artificial intelligence (AI) group at Microsoft, told conference attendees these and other tools for building cloud-native applications, along with GitHub Actions, make it simpler than ever to build applications in an Azure cloud service that includes an integrated continuous integration/continuous delivery (CI/CD) platform.

    Microsoft is also previewing GitHub Advanced Security for Azure DevOps that natively embeds automated security checks using scanning tools into the Azure DevOps platform.

    Other additions to the Azure environment include tools for centralizing the management of application programming interfaces (APIs) using an Azure API Center service that is available in preview.

    The Azure Event Grid has also been updated to enable it to use HTTP to pull delivery of discrete events in addition to pushing them.

    Finally, Microsoft is also previewing generative artificial intelligence (AI) capabilities to make it simpler to manage cloud costs by, for example, using prompts to summarize invoices or breakdown costs.

    Microsoft, along with its GitHub subsidiary, is at the forefront of applying generative AI to application development using tools like GitHub Copilot that developers can use to write better code faster. That copilot capability is now being disseminated across the portfolio of applications and services that Microsoft provides.

    It’s not yet clear what the downstream impact of such tools are just yet, but the overall quality of the applications being built should improve as, for example, fewer mistakes are made that can lead to vulnerabilities.

    Obviously, the way application software is built, constructed and secured is about to change in the generative AI era. Thanks to its alliance with OpenAI, Microsoft has a significant head start on rivals building generative AI platforms that can similarly be applied to improve developer productivity.

    In the meantime, DevOps teams should assume the volume of code simultaneously moving through pipelines is about to dramatically increase as developers become more productive. There will inevitably be more opportunities to apply multiple forms of AI to reduce any DevOps bottlenecks that might arise, but it’s clear most of the immediate benefits are being provided to developers.

    One way or another, however, the overall rate at which applications are built and deployed is about to change drastically. The issue is understanding how those advances will impact downstream DevOps workflows that were constructed for a different era of application development.

  • 5 Ways Traceability Is Changing to Bolster the Remote Workforce

    5 Ways Traceability Is Changing to Bolster the Remote Workforce

    Traceability has always been a useful tool in the development process, but it has become especially important since the COVID-19 outbreak and the increased remote workforce. 

    Where developers and engineers were once working side-by-side, with the ability to discuss their process and keep their team informed, they are now navigating a remote collaboration landscape. According to a 2017 study done by Stack Overflow, there is a correlation for developers between remote work and job satisfaction, and the highest job satisfaction ratings are seen from developers who work remote full time. As technology has grown to make this process easier, remote working is expected to become a norm. 

    Advanced traceability has the potential to hold teams together by allowing increased visibility into each move throughout an entire project. Without traceability, it would be nearly impossible to keep remote teams aligned and on schedule.

    Product development tools have continuously been forced to evolve to keep up with the multi-dimensional nature of requirement, test and risk management. For these processes to be successful, all related variables must work together continuously, at scale, and across teams. 

    We’ve only just started to see how traceability tools can use updated capabilities to streamline the product development process, but we know enough to discuss two things: what’s happening now and what the future may hold.

    Traditionally, traceability could be compared to a map. While not limited to a single view, maps exist to help you navigate your way to a destination. Similarly, traceability leads product developers through every step of their processes, eventually helping them reach their goal. If your map was constantly changing you’d never be able to figure out where you were going, but what if people ahead of you could update it as they went along? This would keep you in the loop of the upcoming twists and turns, and no one would feel blindsided. Traceability makes it easy to share similar production changes with your entire team, all at once.

    In the traceability process, links are built automatically which lets major decision points, reviews and approvals be captured in final documents and reports. This allows for faster and more informed decision making and these live references can exist across versions. 

    With the switch to remote work across the globe, and no immediate end in sight, developers don’t have the option of working side-by-side with their colleagues. Because of this, it is pertinent that they are able to streamline their work in every way possible, and increased traceability is expected to be a pillar of that transition. 

    At the end of the day, connecting the dots is all about making sense of everyone’s decisions. Why did they follow that process, and what factors led them to make the choices they made? 

    In the early days of traceability there wasn’t always room to include every piece of information that you might find relevant down the line. Legacy tools such as the act of manual reporting through Word documents left much to be desired. Today, that’s becoming less of an issue, as developers are allowed more meaningful accountability and insight into interconnections as they happen.

    As we look ahead, we can expect to see these capabilities grow in five different ways.

    Less Manual Effort

    Updating your traceability reports with as little manual effort as possible will be essential to a streamlined, remote workforce. As traceability becomes more advanced, the work to create and maintain it should not become more difficult. 

    More Nuance Captured, Related and Parsed for Meaning

    Improvements in software will make data gathering more precise, and increase the number of items a team can consider relevant, traceable information. This will take additional workloads off of the developers as more items are automatically traced and easily accessible.

    More Attributes Can Define and Predict a Project’s Success 

    If you have a more data-rich, detailed record of activities, it is possible to understand the past with more context and less reliance on costly manual documentation or memory. 

    Dispersed Systems Holding Relevant Information Will Start to Feel Closer and More Interconnected

    Through more dense integration and aligned processes, systems feel more controlled and connected, giving users a more seamless experience.

    Expansion of Communication and Review Capabilities for Stakeholders Who May Be Impacted by Changes

    The availability of a full audit trail of participation will make a big difference in the ease of the review process. The ability to easily see who is impacted by changes will allow teams to proactively manage the effects of said changes.

    In response to the COVID-19 pandemic, and the number of companies who are maintaining their remote work policies, we can expect to see more innovations related to product development workflows. These innovations will enable easier remote collaboration between colleagues and across teams, overall streamlining the product development process.

  • Oracle Adds Low-Code Tool to Autonomous Platform

    Oracle Adds Low-Code Tool to Autonomous Platform

    Oracle this week extended the scope of the cloud services it manages on behalf of customers to include a low-code application development platform based on the company’s Visual Builder development tools.

    Jeff Price, vice president of product Management at Oracle, said Oracle Autonomous Visual Builder (VB) Cloud makes it possible to employ a tool based on JavaScript to build applications that might be written, for example, in Java or, going forward, Jakarta EE. Autonomous Visual Builder Cloud is available via a managed service that can easily integrated with a variety of back-end services managed by Oracle or running on-premises.

    To complement that effort, Oracle also announced the availability of Oracle Autonomous Analytics Cloud and Oracle Autonomous Integration Cloud. Oracle Autonomous Visual Builder comes with tools for accessing back-end services, while Oracle Autonomous Integration Cloud provides a raft of additional connectors for accessing a wide variety of other Oracle and third-party services, Price said.

    Oracle also committed to delivering additional autonomous services later this year to address mobile and chatbots, data integration, blockchain, security and management and additional database workloads such as online transaction processing (OLTP). Those services will complement existing Oracle autonomous database and platform-as-a-service (PaaS) environments.

    Price said interest in low-code development tools is accelerating as organizations look to extend business processes that have been automated using either packaged applications running on-premises or in a software-as-a-service (SaaS) application. Rather than trying to achieve that goal using low-level application programming interfaces (APIs) that are fragile, Price said low-code tools such as Oracle VB make it simpler for even citizen developers to construct applications leveraging code developed by professional developers.

    Organizations need to decide for themselves when to customize those application environments versus taking advantage of them in a turnkey manner, Price said. Organizations tend to heavily customize customer experience and customer relationship management (CRM) applications, while relying on best practices that have been coded into enterprise resource planning (ERP) applications. Oracle is changing the way it supports those applications—base-level support for these applications is now free, but Oracle will continue to charge for premium services.

    The need to customize applications at scale is driving many more traditional enterprise IT organizations to adopt DevOps processes that now need to span multiple IT environments, Price said. He added Oracle now provides integration with multiple continuous integration/continuous deployment (CI/CD) platforms to facilitate that transition.

    As Oracle assumes more responsibility for managing the underlying platforms, organizations in theory should be able to devote more resources to developing applications. To achieve that goal, however, many of them will need to figure out how to extend their DevOps processes to include Oracle as a managed service provider.

    Oracle also provides access to unmanaged infrastructure-as-a-service (IaaS) and (PaaS) services in much the same way Amazon Web Services (AWS) and Microsoft do. Oracle has been late to the cloud game, but this week announced a slew of new cloud customers, including Atomitech Inc., Edith Cowan University, Future Robot, Barrick Gold Corporation, C’s NEXT, Colegio de Bachilleres, Contribute NV, DP World Ltd., Dubai Airport Freezone Authority, Emirates Flight Catering, Hytera Communications Ltd., Ildong Pharmaceutical Co. Ltd., Konyang University, Land O’Lakes Inc., Leshan City Commercial Bank, McDermott, MCore Group, New Hope Liuhe Co. Ltd., Promata, Stallion Oilfield, Ornua Co-Operative, RecVue, Saga d.o.o Beograd, TCI, TaskUs, University of Wisconsin Hospital and Clinics Authority, and Zeneral Heatpump Industry Co. Ltd. All told, Oracle claims to be processing 55 billion transactions a day on its cloud.

    It may take a while for Oracle to catch up to AWS. But if it doesn’t achieve that goal it won’t be for a lack of development tools.

    — Mike Vizard

  • BMC Pushes Automation to the DevOps Left

    BMC Pushes Automation to the DevOps Left

    Much of the inherent conflict that exists between developers and IT operations teams often comes down to how IT automation processes are implemented. IT operations teams generally have their own preferred tools for automating operations while developers have another. To resolve that issue, BMC Software unveiled Control-M Workbench, a set of development tools that extends an application programming interface (API) to allow developers to embed instructions for automating infrastructure using BMC Control-M automation platform.

    Gur Steif, president for digital automation at BMC Software, says Control-M Workbench moves the responsibility for automating the IT infrastructure resources that their application consumes, including the ability to code, debug and test workflows. The IT operations team can then more easily deploy that application in a production environment, he says.

    In effect, BMC Software is enabling IT organizations to put the control of how jobs are executed in a production environment in the hands of developers by moving that function further to the left of the DevOps life cycle. Control-M Workbench represents the first time BMC is venturing beyond its traditional IT operations base to create a tool that will primarily be employed by developers.

    Steif says the goal is to enable IT operations teams to manage much higher volumes of application rollouts. In return for spending a few minutes on installing Control-M Workbench, IT organizations can deliver application 20 percent faster, while running jobs using 50 percent fewer full-time employees. In addition, Stief says production incidents can be reduced by up to 25 percent and batch processing failure rate can drop by as much as 80 percent.

    Control-M Workbench is clearly part of a trend to give developers more control over and responsibility for IT operations. A recent survey of 650 IT decision makers conducted by BMC finds 94 percent of IT decision makers expect automation to spread into all other areas of business by 2020.

    In addition, the survey notes that 73 percent of IT decision makers believe businesses that do not embrace IT automation to achieve the larger digital business strategy within the next five years will cease to exist in 10 years. The top three areas of investment priority in the next 24 months to achieve those goals are containerization, workload automation/scheduling and DevOps. Almost 9 in 10 (89 percent) respondents concur that IT automation needs to achieve their desired digital business objectives.

    However, there are considerable obstacles that need to be overcome, including lack of budget (67 percent), skills (44 percent) and time (51 perent). In fact, 42 percent of the respondents concede that when it comes to digital business initiatives there are conflicting objectives between business units and CIOs that can get in the way of crafting a comprehensive IT strategy.

    DevOps, of course, is more about people and processes than it is technology. Then again, DevOps isn’t going to be willed into existence without providing the tools needed to change the processes. Given the chicken-and-egg relationship between processes and tools, it becomes incumbent on the IT leadership to serve as the catalyst for bringing it all together.

    — Mike Vizard

  • DevOps Chat: BlueOcean Puts CD Pipelines Within Reach of Every Team

    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 staging-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