Tag: cloudbees

  • CloudBees Survey Sees VSM Driving Digital Transformation

    CloudBees Survey Sees VSM Driving Digital Transformation

    A global survey of 600 senior executives conducted by CloudBees suggested a high correlation between investments made in value stream management (VSM) and digital business transformation success.

    The survey found 90% of respondents agreed that organizations that committed to VSM are likely to be further ahead in terms of achieving their digital business transformation goals, with 92% noting VSM also creates more time to focus on innovation.

    Hope Lynch, senior director for platform at CloudBees, said the challenge is that too many executives equate VSM with legacy Six Sigma processes rather than application development and deployment processes that advance digital business transformation initiatives. The survey found that while 90% of senior executives claimed they were familiar with the VSM concept, only half could select the correct answer when asked. In fact, two in five respondents confused the concepts of value stream management and value stream mapping. Nearly two-thirds (72%) of respondents admitted there is still confusion about what VSM is.

    VSM traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved and organizations realize how dependent they are on software, there is a growing appreciation for the value of monitoring things such as the impact of missed software development deadlines on the business. At their core, VSM platforms aggregate DevOps metrics and then match them to a set of key performance indicators (KPIs) defined by business leaders. Once those metrics are gathered and correlated, organizations can apply advanced analytics.

    Eventually, the goal is to apply algorithms and other forms of predictive analytics that will enable organizations to more easily identify the precise impact software development processes have on the business, noted Lynch.

    In the meantime, the CloudBees survey identified manager commitment as the main roadblock to VSM adoption, with 35% of respondents saying getting mid-level employees committed and 31% saying getting senior leadership committed are the biggest roadblocks. That’s a significant issue because more than half of respondents (56%) said C-level executives make VSM investment decisions.

    Survey respondents also reported that scaling VSM efforts throughout the organization is a significant issue for a third (33%) of respondents.

    In general, many VSM initiatives were sidetracked by the COVID-19 pandemic, noted Lynch. However, organizations will now be looking to evaluate the results of those efforts, she added. Digital transformation plans are in place and going well, according to 96% of survey respondents, with only 18% reporting that they are moving, but not fast enough.

    However, all software development processes could be improved by surfacing real-time insights, added Lynch. Most senior executives today don’t have a lot of visibility into the software development processes that are driving multiple digital transformation initiatives, she added.

    In theory, VSM platforms should one day help narrow the divide that has long existed between IT and the rest of the business, as dashboards make it simpler for everyone involved to appreciate the cascading impact a software development decision has across the entire business.

  • CloudBees Demos Orchestration Capabilities of ReleaseIQ Platform

    CloudBees Demos Orchestration Capabilities of ReleaseIQ Platform

    At the online DevOps World 2022 event today, CloudBees demonstrated for the first time the capabilities of the application release management platform it gained last month through the acquisition of ReleaseIQ.

    Shawn Ahmed, chief marketing officer and interim chief product officer at CloudBees, told conference attendees that the ReleaseIQ platform will provide application development teams with visibility into precisely how their code is making it into production environments.

    Armed with those insights, it then becomes possible to understand exactly how the way commits are made during a build process are, for example, creating a workflow bottleneck, he added.

    The ReleaseIQ platform is designed to enable DevOps teams to both create and maintain pipelines using a no-code tool. That enables greater transparency into workflows via dashboards that also provide optimization recommendations.

    CloudBees already provides a Flow orchestration engine within its continuous delivery platform. However, ReleaseIQ provides a similar capability across multiple continuous integration/continuous delivery (CI/CD) platforms using a SaaS platform that is more accessible. ReleaseIQ can also be integrated with multiple platforms including CloudBees CI, Jenkins, CircleCI, GitLab, Bamboo, ArgoCD and others.

    Naturally, the current level of DevOps maturity varies widely by organization. However, as more organizations realize how much they depend on software to drive digital business transformation processes, the need to further automate application development and delivery becomes more apparent. While CI is widely used today, the number of organizations that have consistently implemented CD to automate application release management is still fairly limited. The underlying infrastructure that software is deployed on typically has a unique set of application programming interfaces (APIs) that each CD platform needs to support. Platforms such as ReleaseIQ provide a higher level of abstraction that simplifies managing the pipelines that deliver software.

    CloudBees is essentially positioning ReleaseIQ as the orchestration engine for both unifying pipeline management and, ultimately, enabling value stream management across increasingly complex application development environments. It may take a while to fully realize that ambition, but with the acquisition of ReleaseIQ, the company is now pursuing a more cloud-centric approach toward enabling DevOps teams to, for example, more easily reuse pipelines.

    DevOps teams, of course, have created a lot of scripts over the years to provide orchestration capabilities. The issue is that those scripts tend to be brittle in the sense they don’t scale especially well over time. They also tend to be poorly documented and challenging to maintain if the script writer leaves the organization. It’s not uncommon for new members of a DevOps team to replace a script with one they wrote simply because they’re more familiar with how it’s constructed.

    More than a decade after the launch of the Jenkins CI/CD platform, there are still plenty of manual DevOps processes that should be more automated. A no-code orchestration platform may prove to be a significant step toward automating a wide range of tasks that consume more time than they should.

  • Business Leaders Will Trade Speed for Security

    Business Leaders Will Trade Speed for Security

    A global survey of 600 C-level executives conducted by CloudBees found that when it comes to building software, more than three-quarters of respondents said it is more important to be secure and compliant than fast and compliant.

    As a result, more than three-quarters (77%) also noted their organization is implementing a shift left strategy for implementing security and compliance even though 58% recognized that those efforts created additional burdens for developers.

    Three-quarters of respondents also conceded that compliance (76%) and security (75%) challenges limited their company’s ability to innovate. Nevertheless, 83% said shift left is important for them as an organization despite the fact that 88% of executives said their software supply chain is secure or very secure. However, only 33% of respondents said their software supply chain is completely compliant.

    Not surprisingly, 86% are focusing on compliance more now than they were two years ago and, in the wake of a series of high-profile breaches of software supply chains, 82% are more concerned about attacks.

    CloudBees CEO Anuj Kapur said it’s clear there is a greater need to reduce security and compliance burdens for developers by putting guardrails in place that automate DevSecOps processes. The survey noted that only 22% of executives believed their software delivery supply chain is completely automated, while another 37% said it is close to being automated. Only 22% said their compliance process is completely automated, with 35% believing it is almost completely automated.

    Three in five (59%) executives said they have all, or mostly all, external tools for security and compliance issues and 29% said they have a mix of internal and external tools. Only 11% use mostly internal tools. A full 90% said their risk management team has the tools, knowledge and expertise to build and/or maintain a secure software supply chain.

    The real challenge, of course, is that while compliance issues are relatively static, new security issues arise all the time. Developers make mistakes or a new zero-day vulnerability is discovered after an application has been deployed in a production environment. It’s critical for organizations to embrace automation to enable developers to address those issues as part of a continuously automated update cycle, noted Kapur.

    As more responsibility for compliance and security is shifted left, the degree to which DevOps workflows will need to be adjusted will naturally vary by organization. However, the days when developers could ignore security issues during the application development process are all but over. The leadership of organizations of all sizes are making it clear they want to see a reduction in the number of security and compliance issues that arise in production environments.

    Ideally, efforts to build more secure and compliant applications would not slow down the rate at which applications are being built and deployed. However, the CloudBees survey made it clear that more executives are willing to prioritize security and compliance over speed of application development. The issue is how to strike a balance between what are clearly two competing priorities.

  • CloudBees Acquires ReleaseIQ to Advance DevOps Orchestration

    CloudBees Acquires ReleaseIQ to Advance DevOps Orchestration

    CloudBees announced today it has acquired ReleaseIQ, a provider of an orchestration platform for automating software delivery via a software-as-a-service (SaaS) platform.

    Sacha Labourey, chief strategy officer for CloudBees, said the addition of ReleaseIQ to the CloudBees platform will provide more visibility into and control over software delivery on an end-to-end basis.

    CloudBees already provides a Flow orchestration engine within its continuous delivery platform. However, ReleaseIQ provides a similar capability across multiple continuous integration/continuous delivery (CI/CD) platforms using a SaaS platform that is more accessible.

    The ReleaseIQ platform is designed to enable DevOps teams to both create and maintain pipelines using a no-code tool. That enables greater transparency into workflows via dashboards that also provide optimization recommendations. That capability makes it much simpler to troubleshoot software deployments.

    Labourey said that while ReleaseIQ can be integrated with multiple platforms including CloudBees CI, Jenkins, CircleCI, GitLab, Bamboo, ArgoCD and others, the primary focus will remain on the open source Jenkins platform that still owns the lion’s share of the DevOps market. The overall CloudBees goal remains to employ automation and remove as much friction as possible from DevOps workflows as part of an ongoing effort to improve developer productivity, he noted. CloudBees, however, regardless of the level of DevOps maturity within any organization, is committed to meeting customers where they are versus requiring them to rip and replace existing investments, Labourey added.

    The overall level of DevOps maturity may vary widely both within and between organizations. However, as more organizations realize the extent to which they depend on software to drive digital business transformation processes, the need to further automate application development and delivery becomes more apparent. While CI is widely used today, the number of organizations that have consistently implemented CD is fairly limited. The underlying infrastructure that software is deployed on typically has a unique set of application programming interfaces (APIs) that each CD platform needs to support. Platforms such as ReleaseIQ provide a higher level of abstraction through which managing the pipelines that deliver software becomes simpler.

    In general, most organizations are trying to strike some level of balance between centralizing the management of DevOps workflows and enabling development tools to adopt whatever tools they prefer. It’s not uncommon for application development teams to independently adopt any number of tools that ultimately need to be integrated with a DevOps toolchain. Each of those tools, however, contains metadata that needs to be shared with a centralized orchestration engine that automates a range of tasks across multiple pipelines based on the metadata collected from each tool.

    There are, of course, still a lot of manual DevOps processes that should be automated. CloudBees is positioning ReleaseIQ as the orchestration engine for both unifying the management of pipelines and, ultimately. enabling value stream management across increasingly complex application development environments. It may take a while to fully realize that ambition, but with the acquisition of ReleaseIQ, a new foundation is being laid.

  • DevOps World 2022: A DevOps Retrospective

    DevOps World 2022: A DevOps Retrospective

    With the seminal IT conference DevOps World 2022 in Orlando September 26 to September 29 upon us, I think about the pivotal industry conferences and events critical to my path to the cloud, DevOps and cloud-native. It brings me to this brief retrospective, highlighting some of the most significant influences that still guide my path today.

    I highlight these for you as conferences, books, emerging development tools, and changes in infrastructure delivery all played critical roles in my completely rethinking of how we create software through DevOps.While leading IT for a global R&D industry consortium from 2010 to 2016, I was unknowingly in the middle of a significant shift from designing network protocols to entirely moving to the cloud, creating self-service development portals and automating the development process.

    This journey began partly when a friend and colleague, Alan Shimel, creator of the then-new devopsy.kinsta.cloud site, said, “Check out this thing called DevOps … and you gotta read this book!” Looking back at my Amazon order history, I see I first purchased The Phoenix Project in November 2013. The book immediately became the main topic of discussion among my engineering team. While we didn’t label it as a DevOps tool then, Jenkins established the basis of our DevOps toolchain across multiple software-based research projects. Other technologies, including Artifactory, Maven, Git, GitHub, Bamboo and OpenShift, for example, quickly followed, enabling us to spin up development environments for many new software projects. In less than a year, we completely retooled IT from a significant bottleneck to becoming the easiest path to creating new software projects by equipping teams with DevOps, development tools, environments and cloud platforms.

    Jenkins World (now DevOps World) helped me understand the central roles CI and CD played in creating automated workflows and delivering software more quickly from development into test environments. The first AWS re:Invent helped me rethink the cloud, from a data center scarcity mindset to making compute, storage and bandwidth resources harnessed through automation and a credit card. I wrote my first post about DevOps in 2014, The DevOps Journey, where I did my best to make sense of precisely what DevOps is.

    As I go back and reread that post, I’m surprised how much of those thoughts still apply in 2022. Today, I continuously read many technical books, learn from thought leaders and attend influential conferences, including this year’s DevOps World. I wonder what will change how we think about and create software again in the next decade!

    If you can, join us in Orlando for DevOps World. Techstrong.TV will be broadcasting live from the event; if you can’t make it, we’ll keep you updated on all of the developments announced there. Also, join us in November for our own DevOps Experience virtual event, which will highlight DevOps Everywhere: The Edge and Beyond. Hope to see you soon!

     

  • DevOps World 2022: DevOps Tail Wags the Dog of Digital Business

    DevOps World 2022: DevOps Tail Wags the Dog of Digital Business

    As a methodology for building and deploying applications faster, DevOps has been around for more than a decade. But it’s only now that the methodologies and concepts pioneered years ago are starting to wag the dog of digital business transformation.

    Since the onset of the COVID-19 pandemic, digital business transformation has been all the rage. Organizations of all sizes now have a much deeper appreciation for digital processes that enable them to respond more adroitly to changing business conditions regardless of whether the global economy is expanding or contracting.

    DevOps Wags the Dog

    Not too long ago, ironically, business executives routinely complained that IT simply wasn’t fast enough to keep pace with the needs of the organization. At the CloudBees DevOps World 2022 conference in Orlando next month, it will be made crystal clear that businesses are now adopting concepts originally defined by DevOps pioneers to not only keep pace with the current rate of application development innovation but in many ways actually manage the business itself.

    As Mitch Ashley, principal analyst for Techstrong Research, an arm of Techstrong Group, publisher of both devopsy.kinsta.cloud and Digital CxO, recently noted during a podcast, “It’s all about the software.”

    Of course, the shift in the relationship between IT and the business it supports has been a long time coming. The debate over how to close the divide between IT and the rest of business has been going on for decades. Even with the rise of DevOps, it’s been more than 11 years since the Jenkins continuous integration/continuous delivery (CI/CD) platform was officially launched. Today, advances in IT are now happening at a rate that many businesses are struggling to absorb.

    In fact, what started out as small teams of application development and deployment specialists looking for ways to automate the building and deploying of applications has now evolved into a multi-billion dollar sector of the software industry. And it is driving a level of business transformation that hasn’t been seen since PCs running word processing and spreadsheet applications arrived in the 1980s.

    Software is (Still) Eating the World

    Just how big an impact DevOps is going to have going forward is still to be seen. It’s still early days as far as pervasive adoption of DevOps best practices is concerned but, as Marc Andreessen once noted, software continues to eat the world. Today, the bulk of that software is being constructed with DevOps best practices in mind and using everything from containers to serverless computing frameworks that make it simpler than ever to add new capabilities to applications both inside and outside of the cloud. The pace at which technological innovations are being made is only going to accelerate.

    As such, it’s arguably never been more important for DevOps professionals to gather in person to share knowledge and insights. During the COVID-19 pandemic, DevOps platforms evolved tremendously. The teams that use those platforms exercise more influence than ever within their organizations. The best way to appreciate the value of DevOps has always been to learn firsthand how practitioners are employing those principles to achieve a wide range of strategic business goals.

    No matter how large or small the organization, the need to embrace and then continuously improve DevOps processes and workflows is, as always, a pressing concern. Achieving that goal in isolation may be possible, but there’s no doubt in anyone’s mind there’s nothing quite like spending a few days with a few thousand like-minded souls to make attaining those goals a whole lot easier.


    Want to learn more about this and other related topics? Join CloudBees for DevOps World 2022, held in Orlando, Florida, at the World Marriott Center. Use discount code DW22 when registering and get access to all the fantastic offerings, including keynotes, sessions, training and other interactive activities. We can’t wait to see you there for the DevOps Remix!

  • Infographic: 8 Trends Shaping Software Delivery in 2022

    Infographic: 8 Trends Shaping Software Delivery in 2022

    [pdf-embedder url=”https://devopsy.kinsta.cloud/wp-content/uploads/2022/09/INFOGRAPHIC-8-trends-shaping-the-future-of-software-delivery-in-2022-Final.pdf” title=”INFOGRAPHIC – 8 trends shaping the future of software delivery in 2022 – Final”]

  • DevOps World 2022: Why DevOps Needs a Remix

    DevOps World 2022: Why DevOps Needs a Remix

    I was checking out the DevOps World website today to gather information, as Techstrong.TV will be live streaming from the show in Orlando, Florida September 28 and 29, 2022. The theme for this year’s DevOps World is “DevOps Remix.” The more I thought about it, the more it became clear that DevOps Remix is a perfect theme for DevOps World—and for DevOps as a practice.

    What does a DevOps remix mean? Well, I won’t pretend to speak for CloudBees, the event’s host, but here’s what they have on the DevOps World website:

    “The tempo will be faster, more energized, and more harmonious in keeping with the accelerated pace of the DevOps transformation. Progressive delivery, value stream management, and everything from AIOps to XOps are now part of the mix creating new paths, new beats, and faster code releases.”

    That’s what a DevOps remix means to them; here’s what DevOps remix means to me.

    I believe a DevOps remix speaks to the continuing maturation of DevOps as a methodology and a practice and to the DevOps market and community. DevOps is no longer nebulous; there’s no longer a question of “Is it real or not? What exactly is DevOps?” kind of thing. No, DevOps is very much a player in the software development life cycle (SDLC). So much so that as digital transformation continues to involve software in places it hasn’t been before, DevOps is helping it get there. DevOps is going places it has never been before.

    Techstrong Group’s own DevOps Experience event, now in its fifth year and coming this November, has a similar theme: DevOps Everywhere. DevOps, as part of the CI/CD pipeline, still exists, but DevOps today is so much more. To be successful today, organizations large and small (but especially enterprises) need to take DevOps fundamentals and implement them whenever and wherever they are building, deploying and managing software.

    Another reason the idea of a remix is so appropriate is that, as the world emerges from COVID-19 lockdowns, there is something comforting about revisiting in-person events, conferences and training—the ‘normal’ industry activities and events that happened before the pandemic. For those of us in the DevOps space, DevOps World is one of those things. I have been going to DevOps World since before it was even called DevOps World—when it was Jenkins World. There’s a remix for you!  

    DevOps does need a remix, and it’s happening right now. While I do think it’s great to be able to resume many of the same activities, go to the conferences and get training, I don’t expect this year’s DevOps World to be like previous editions in San Francisco or online. That’s part of what makes it such a terrific event—a mix of the old, the new, the tried and true, the cutting edge and the familiar. So, if you consider yourself a member of the DevOps community and can make it to Orlando at the end of September, you should consider being part of the DevOps Remix.

    This year, DevOps World will be held in Orlando, Florida, at the World Marriott Center. The CloudBees folks have published a discount code, DW22, to use when registering that should save you some money on a full ticket for the show, including some training, some great sessions and interactive activities. We can’t wait to see you there for the DevOps Remix!

  • Designing Your DevOps Ecosystem for Multi-Cloud

    Designing Your DevOps Ecosystem for Multi-Cloud

    As companies grow and expand to become global enterprises, IT infrastructure inevitably becomes more complex. When it comes to cloud computing, that usually means maintaining multiple clouds. There are many reasons for using different cloud service providers (CSPs)—some by choice and others by mandate. 

    For instance, a large enterprise with operations around the world may choose to use an in-country cloud vendor to be closer to the customer, therefore reducing latency and increasing application performance for operations in that country. Alternately, in some countries, data residency laws require that certain kinds of data reside on cloud providers within the country’s borders, which means companies with local operations can only use a cloud provider in that country. Both circumstances lead companies to maintain multiple clouds to facilitate operations at scale. Additionally, a company may decide to use two or more cloud providers as part of a fallback strategy to automatically reroute network traffic to another provider if a major outage occurs.   

    Regardless of whether the use of multiple CSPs is a choice or a mandate, enterprise IT leaders—and DevOps teams in particular—need to think strategically about multi-cloud environments and design their software delivery ecosystem from the outset to accommodate a multi-cloud strategy. 

    Best Practices for Multi-Cloud Environments

    An effective multi-cloud DevOps strategy is essential for allowing businesses to easily scale application delivery across many different cloud assets and is therefore vital for enterprises operating globally. To create an effective strategy, consider these best practices.

    Use a Centralized Software Delivery Platform

    With many CSPs—each with different requirements and tools—companies too often create siloed software development and delivery teams by vendor (AWS, Azure, GCP, etc.) or functional role (security, compliance, etc.). To avoid this pitfall and maintain control and visibility across all cloud providers, it’s important to implement a centralized software delivery platform, ideally one that’s environment agnostic. This will give your DevOps leaders the intelligence and insight they need to manage the entire software delivery ecosystem across multiple clouds anywhere in the world. At the same time, automated delivery processes can ensure quality checks and other milestones aren’t missed regardless of the cloud destination and that reporting, analytics and metrics from a centralized platform can identify and eliminate bottlenecks across different clouds. 

    Use Cloud-Agnostic Tools

    Most cloud vendors have their own tools. However, maintaining a multi-cloud environment using vendor-specific tools can lead to lock-in and which can be costly and time-consuming to remediate. Too often, when companies move to the cloud, they use a set of vendor-specific tools for their software delivery processes. That works well initially, but as the company scales and requires a multi-cloud approach, the teams either find themselves heavily siloed without visibility across the whole ecosystem or there is significant technical debt that needs to be overcome. To avoid this, companies need to plan for the use of cloud-agnostic development and deployment tools from the outset so you can easily shift applications to different cloud providers as necessary to keep pace with changing business needs.

    Create Cloud-Agnostic Templates

    As developers assess and use tools and applications for different clouds, environments and use cases, they can create templates and abstracts to share lessons learned across teams, increase productivity and speed development cycles regardless of the destination CSP. For enterprises with more advanced DevOps practices, self-service capabilities—like a shared module catalog—can further speed development processes. 

    Make the Most of a Multi-Cloud Environment

    Once your enterprise has embraced a multi-cloud approach and the DevOps systems and processes are in place to efficiently deploy applications across different CSPs, a multi-cloud environment can be used to your strategic advantage—to increase flexibility, speed software delivery and reduce costs. Here’s how:

    Align Application Destinations to Specific Clouds

    When you’re not dealing with the confines of country-specific cloud providers, IT and DevOps leaders can strategically align applications to specific cloud providers by region or country to reduce latency, optimize workloads or take advantage of specific service offerings from a particular CSP.

    Use Application Features in Different Clouds

    This concept is a great way for DevOps to leverage a multi-cloud architecture. If an application is run in one cloud and you want to add a feature that uses an application from a different cloud in your IT footprint, you can create a multi-cloud cluster using the same underlying cloud database to support both workloads. In this scenario, a production node resides in cloud A and runs in parallel to the read-only node in cloud B. This helps developers avoid the headaches that come with custom scripting as well as the costs of maintaining a backup and restore scenario.

    Reduce Costs and Improve Performance with Cloud Arbitrage

    This strategy is somewhat new, but it’s becoming more and more mainstream as competition increases among cloud providers. Here, you use a multi-cloud cluster to shift your workloads among several cloud providers to optimize your cloud environment and take advantage of negotiated discounts, specialized support, higher availability, lower latency or other unique features offered by a specific CSP.

    To keep pace with our rapidly changing world, enterprise-scale organizations must be able to manage software delivery across multiple clouds. If your DevOps systems and processes aren’t designed for flexible development and delivery across different CSPs, you could limit your ability to adjust and successfully manage major disruptions or scale to take advantage of new opportunities.

  • ReleaseIQ Adds Orchestration Tool for Multiple Instances of Jenkins

    ReleaseIQ Adds Orchestration Tool for Multiple Instances of Jenkins

    ReleaseIQ has launched an orchestration framework for the open source continuous integration/continuous delivery (CI/CD) environment that makes it possible for DevOps teams to orchestrate pipelines across multiple instances of Jenkins.

    Seetharam Param, ReleaseIQ CEO, said ReleaseIQ Essentials for Jenkins is an implementation of an existing orchestration platform that enables DevOps teams to orchestrate pipelines across heterogeneous CI/CD platforms.

    The challenge is that organizations that have standardized on Jenkins typically have multiple instances being used by not only different IT operations teams but also owners of, for example, ancillary quality assurance processes. ReleaseIQ Essentials for Jenkins provides an alternative approach to the orchestration tools that CloudBees, the original developer for Jenkins, provides, said Param.

    Jenkins today is being advanced independently of CloudBees as an open source project managed by the Continuous Delivery (CD) Foundation, which is an arm of the Linux Foundation. Founding members of the CD Foundation include CloudBees along with Alauda, Alibaba, Anchore, Armory, Autodesk, Capital One, CircleCI, DeployHub, GitLab, Google, Huawei, JFrog, Netflix, Puppet, Red Hat, SAP and Snyk.

    ReleaseIQ Essentials for Jenkins optimizes execution of jobs and pipelines and also provides DevOps teams with a no-code graphical interface to build pipelines.

    DevOps teams can also import and execute Jenkins pipelines and jobs in addition to being able to pre-merge pipelines.
    Finally, DevOps teams are provided insights based on key metrics the platform automatically tracks on their behalf. Those metrics make it possible to quickly discover and fix pipeline issues across multiple Jenkins instances via console log aggregation, noted Param.

    It’s not clear to what degree DevOps teams that have standardized on Jenkins might swap out one orchestration tool for another. However, Param said more organizations are either wary of becoming locked into a specific CI/CD platform or now find themselves in a position where they need to continue employing multiple CI/CD platforms from different vendors. The ReleaseIQ platform provides a means for orchestrating pipelines regardless of how many different CI/CD platforms are employed, noted Param.

    It’s clear the need to embrace orchestration tools is becoming more pronounced. DevOps teams are spending too much time manually maintaining DevOps pipelines. The need for tools to automate the management of DevOps workflows is becoming critical as the number of application development projects that are simultaneously being launched continues to grow. Arguably one of the reasons that DevOps processes are not as widely embraced as they might be is the level of expertise required today to manage all the pipelines that make up a workflow.

    Of course, the level of DevOps maturity varies greatly by organization. It’s not uncommon for even different teams within the same organizations to have significantly different levels of proficiency. The challenge and the opportunity now is to provide those DevOps teams with tools that operate at a high enough level of abstraction to make DevOps accessible to every IT professional regardless of the level of programming expertise they may or may not have.