The pace of software development continues to accelerate as organizations continue to march down the digital transformation path—and continuous delivery may grow into a staple of this process. Early and founding members of the Continuous Delivery Foundation came together at last week’s DevOps World / Jenkins World conference in San Francisco to talk about their plans to build up a home for neutral collaboration in this sector. In a keynote address, companies such as HSBC, CloudBees, Google, and Netflix shared their hopes for the further development of best practices through the foundation for continuous integration (CI) and continuous delivery (CD) in software development.
Part of the presentation showcased projects such as Jenkins, an open source automation server, as a part of the CI/CD movement.
A desire to smooth over pain points in software development led to the creation of Jenkins, which automates parts of the development process. Kohsuke Kawaguchi, the creator of Jenkins, spoke during the keynote about the origin of his automation server and its forward evolution. He currently serves as chief scientist for CloudBees, the host of the conference.
Jenkins has its roots in Kawaguchi’s time as a software engineer at Sun Microsystems. “One afternoon, I broke one too many builds and I got a phone call from my colleagues,” he said. This led to Kawaguchi musing about creating a program that could catch his mistakes before his coworkers did. “That’s kind of how the whole thing started,” he said.
Breaking a build is akin to tugging on a thread and unraveling a garment, only in this instance the thread is code and what might unravel is an app that other engineers are also working on.
Kawaguchi joked that his experiences breaking builds were likely shared by everyone in the audience and suggested it’s a widespread occurrence that Jenkins could help with.
He shared the stage with a host of members of the Continuous Delivery Foundation that included leadership from the DevOps Institute and the Cloud Native Computing Foundation. They collectively offered insights on how continuous integration and delivery needs an impartial forum. They believe further discussion can help clear up confusion as the sector advances in size, scope, and pervasiveness.
Laying a Foundation
The Continuous Delivery Foundation saw some familiar hands take part in its creation. Chris Aniszczyk, CTO at the Cloud Native Computing Foundation and a vice president at the Linux Foundation, described the Linux Foundation as having a “foundation as a service model” to help projects and communities thrive. He said discussions were brewing in the developer scene about CI/CD, tools such as Jenkins, and whether the Linux Foundation community could get involved in establishing a neutral ground to sustain collaboration in this space.
As CI/CD grew rapidly, the variety of tools being used, Aniszczyk said, made operations somewhat hectic. “There was a bunch of tools distributed amongst our organization and it was a cause of pain,” he said. “Fragmentation is not fun if you try to move to different systems.” There were also complaints about no clear best practices in terms of documentation. Multiple conversations about CI/CD open source projects such as Jenkins and how best to support them led to the launch in March of the Continuous Delivery Foundation as neutral home for industry collaboration, he said. “We’ve just started. It’s super early days. It’s been less than half a year since we fully announced this.”
HSBC became a founding member of the Continuous Delivery Foundation to help further development of the CI/CD space, especially for critical operations. Rajeev Mahajan, global head of DevOps engineering at HSBC, said he admired the processes of airlines, which constantly have aircraft in the air typically without panic or surprises. “One small mistake there is the difference between life and death,” he said.
That type of efficient control in the face of complex and critical operations was something Mahajan sought to emulate. “For us, the CI/CD pipeline is part of our DevOps transformation,” he said. It touches payment processing, security, and other aspects of the organization. Layers of complexity have naturally built up over time, Mahajan said, so establishing best practices to address this became essential. “When we started our DevOps journey, we had basic pipelines that we matured into very advanced pipeline,” he said. “This is a continuous improvement process for us.”
The Human Element
The potential for collaboration got Jayne Groll, CEO of the DevOps Institute onboard with the Continuous Delivery Foundation. She said that automation is an essential ingredient to CD and without it the fast production flow from ideas to realization is limited. “But it’s not the most essential ingredient in this recipe,” she said. “It’s the human factor, the human ingredient that’s going to make continuous delivery a success.” Groll added that the mission of her institute is to advance the human element of DevOps. “We felt it was really important to support an initiative like the Continuous Delivery Foundation by bringing the human perspective into the equation. Humans need to be upskilled, innovative, and disruptive. Only humans bring that perspective.”
Streaming Giant Goes CI/CD
A Specification in Place of a Standard
Google’s Tekton is another project that joined the Continuous Delivery Foundation. Tara Hernandez, senior engineering manager at Google Cloud Platform, spoke about Tekton, which is a Kubernetes-native open-source framework for the creation of CI/CD systems. Flexibility and compatibility are part of Tekton’s DNA, she said. “We realized early on that there is a massive benefit to collaborating.” Hernandez is also a member of the technical oversight committee for the Continuous Delivery Foundation. She cautioned against pushing for standards as teams want to clear up confusion. “Standards are made to be broken,” Hernandez said. “We don’t want 14 standards.” Tekton provides a specification rather than a standard, she said, and it works on any hosted platform. “It’s like a thermostat. ‘Is your code not up to date? Better rebuild and redeploy that container.’”
They Grow Up So Fast
A sub-project of Jenkins has taken on a life of its own as Jenkins X, a CI/CD solution for applications on Kubernetes. Jenkins X is now an independent project within the Continuous Delivery Foundation.
The development of Jenkins X is an effort to automate CI/CD for the cloud. “Jenkins X can use either Jenkins or Tekton,” said James Strachan, co-creator of Jenkins X. “Under the covers ... it looks and feels the same.”
Strachan is also a distinguished engineer at CloudBees and said the last decade has seen significant changes in how software is built, packaged, deployed, and operated. “We’re all moving away from virtual machines for containers because they are smaller and cheaper to manage and run,” he said. The ubiquity of Kubernetes and other changes are making many platforms look and feel like cloud, he said. “We have a single way of packaging software and deploying software anywhere.”
There are also changes in how teams and code are organized, Strachan said, away from monolithic structures to smaller teams to quickly develop microservices. “We’ve all realized that every business is a software business,” he said. “All of us need to get better at delivering business value quickly through software.”
Joao-Pierre S. Ruth has spent his career immersed in business and technology journalism first covering local industries in New Jersey, later as the New York editor for Xconomy delving into the city's tech startup community, and then as a freelancer for such outlets as ... View Full Bio