While the ambitions of software development teams and the C-suite are ultimately the same, each has slightly different priorities. The boardroom wants to see software applications delivering value, being built securely, on time and budget, and agile enough to adapt to change. DevOps teams working under the CTO want to iterate more quickly and build and test innovative applications that will scale.

Successful software-centric companies achieve these goals in the startup phase by organically building their tooling, infrastructure and systems. Thanks to the ubiquity of open-source solutions, from low-level libraries to software delivery lifecycle (SDLC) platforms, initial progress can be swift – at least in terms of company growth.

While the ambitions of the emerging management layers in a growing business and its core IT teams remain the same, practical problems can begin to arise at the developer’s workstation. In a previous article, we discussed some of the issues surrounding the daily use of Jenkins, the de facto standard used to manage CI/CD pipelines. The bottlenecks created, on occasion, by using Jenkins at scale indicate some of the common problems encountered in commercial software development pipelines.

Speaking exclusively to Tech HQ, Wesley Pullen (Field CTO within CloudBees) described a typical scenario. “I stand [Jenkins] up, and it’s good,” he said. “It’s not until more and more developers and teams get added to my Jenkins instance when things can start to get frustrating.’

“Jenkins is definitely one of the most successful CI/CD automation systems in the world with 44% of the CI/CD market share!  It has an enormous eco-system of plugins that many users enjoy and take full advantage of. If you need to integrate with a software technology, odds are that there is a plugin in the eco-system for that integration. The challenge can come in when it is time to scale, administer, and manage Jenkins instances.

Most companies work with existing investments in technology, often dismissed as ‘legacy’. Finding ways to manage a software development lifecycle on existing systems effectively is a big ask.

To take an extreme example, the presence of WebSphere or a COBOL codebase alongside microservices makes the C-suite’s questions most often asked of development teams challenging to answer; How long? How safe? How much?

Software development lifecycles are definitely getting longer, and the companies managing what Google terms an ‘elite’ release cadence – once a day or more often – have all but disappeared in the last few years. Addressing the issues behind the slow-down will separate a company from its competitors’ slower time-to-market.

DevOps team leaders could easily point to a dozen or more solutions on the market that will automate software build cycles for increased speed, but the vast majority require a tear-down and retooling, not least for some of the extant systems. But the CloudBees toolset allows enterprise customers to capitalise on their IT investments that reach as far back as the early AS400 mainframe days.

Mr Pullen says his company’s approach is “embrace, don’t replace, we’ve got you covered.” Embrace and harmonise is the approach that’s practical, cost-effective and realistic.

Part of the problem in a slow iterative cycle is security. While some fastidious developers who write core code and libraries, pulled daily from repositories, supply software bills of materials (SBoMs), they are not in the majority. It’s contingent on application developers, therefore, to adopt rigorous security procedures in-house. The danger is that observing software governance and security might slow down app development further. Developers are not security experts by training, but, as Mr Pullen said, they can be guided.

He added: “There’s a danger of developers getting cognitive overload. Our users can inject policies into their pipelines [and/or] releases within CloudBees, so we provide ‘guard rails,’ like the ones [that] kids use at bowling alleys. Developers get into better habits in their code commits. We cover for developers like we cover for our children during their process of learning to bowl.”

While CloudBees’ initial offering was often described as just ‘Jenkins for the enterprise’, its Integrated Software Delivery Platform (ISDP) now comprises multiple interoperable solutions that cover CI, CD, Release Orchestration, DevOps Analytics, Service Catalog (e.g. IDP), Feature Management, and Continuous Compliance.

You’ll find CloudBees in many companies that used or continue to use Jenkins, and it’s that platform’s shortcomings at scale that piqued the interest of developers whose workflows were impacted by so-called ‘Jenkinsteins’ – deployments that were once perfect for small teams but couldn’t cope effectively with multiple teams at enterprise scales. For example, CloudBees CI was the natural evolution for fintech Broadridge, which was keen to build on its existing skill base.

“We can take this engineering brilliance, all this creativity, this, in many cases, lifetime of knowledge and learning and just wrap it with a tool [CloudBees CI] that helps us to do that,” said Daniel Ritchie, Distinguished Engineer at Broadridge.

Other companies, many of them household names, use CloudBees’ Integrated Software Delivery Platform (IDSP) to ensure development and operations teams deliver projects on time, within budget and with security and software governance practices baked into their workflows. Those companies’ C-suites see the value produced by teams equipped with the CloudBees tools and the existing stack. Teams work with familiar technology and workflows, old and new, from PASCAL and waterfall to Node and Agile. They deliver software outcomes reliably, securely and on time.

To read more case studies, head over here, or to explore your organisation’s requirements in more depth, click here.