The CD Foundation (CDF) and premier member Cloudbees are announcing the transition of Jenkins Area Meetups (JAMs) to CI/CD Meetups. This is an important change. Under the CDF umbrella, the CI/CD community will be able to cover a broader range of topics and technologies that will include Spinnaker, Tekton, or general CI/CD. Our goal for this transition is to grow and foster collaboration within the CI/CD community.
How Do I Get Involved?
Want to join an existing meetup? There are over 106 groups in 39 countries with a total of over 34,000 members, find one near you: https://www.meetup.com/pro/cicd-cdf
Want to start a meetup? Drop me a line, I’d love to hear your idea: jsalinas@contractor.linuxfoundation.org
Thank you!
I just want to express my gratitude to the open source community. The Continuous Delivery Foundation (CDF) would not be here about to host our first North America CD Summit on November 18th at Kubecon 2019 San Diego without your contributions.
Since the launch of the CD Foundation in March of 2019 our charter has been to serve as the vendor-neutral home for the most important open source projects for continuous delivery and specifications to expedite the release pipeline process. The first projects to be hosted by the CDF include Jenkins, Jenkins X, Spinnaker, and Tekton. Our goal at the CDF is to help facilitate an open governance model that encourages participation and technical contribution from the community. The CDF will provide a framework for long-term stewardship and sustainability for CI/CD tools part of the foundation.
Our first step towards this was to ask the existing JAMs organizers to work with us to transition the Jenkins Meetup Pro account to CDF. This means each meetup organizer has more tools and options within meetup.com for organizing meetups and connecting with their local community. You can create customized mailing lists, integrate with Mailchimp, and track the growth of members and RSVPs over time. The overall Meetup Pro account has been rebranded to CDF. JAM organizers are welcomed to transition their meetup to CI/CD to include all four projects, but by no means are they under any obligation to do so.
We cannot wait to see our community grow and what 2020 has to offer!
Author: Dan Lorenc (dlorenc@google.com, twitter.com/lorenc_dan, github.com/dlorenc)
Last year at Kubecon Seattle, Tekton was just an idea in the heads of a few people, and a bit of code inside knative/build-pipeline. Fast forward to today, and we have a thriving community, independent governance inside a great foundation, and we’re quickly approaching our beta release! This year has flown by, so I wanted to highlight some of the original goals of the Tekton project, and some of the milestones we’ve hit toward them.
The Start
When Christie, Jason and I started sketching out the original Tekton APIs on a whiteboard in San Francisco, we had a straightforward goal in mind: make the hard parts of building CI/CD systems easy. There are already dozens of CI/CD systems designed to run on kubernetes, and for the most part they all have to build the same basic infrastructure before they can start solving customer problems. Kubernetes makes scheduling, orchestration and infrastructure management easier than anyone could have imagined, but it still leaves users with a few pieces to assemble before they can use it as an application delivery platform.
These were some of the original whiteboard sketches on what later became the Tekton Pipeline CRD.
Things like basic DAG orchestration, artifact management, and even reliable log storage are outside the bounds of the core Kubernetes APIs. Our plan was to use the new Custom Resource Definition feature to try to define a few more “nouns”, on top of the existing Kubernetes primitives, that were better suited for Continuous Delivery workloads. In doing so, we would make it easier for people and trans to create delivery systems designed for their exact use cases, while making sure the underlying primitives allowed for some degree of compatibility.
Vague ideas are great, but it’s much more productive to collaborate with others when you have something concrete to share and get feedback on. So in August of 2018, we released the sketch and principles we used to design it on knative-dev and to a few other interested parties. The feedback was amazing. The core pipeline team on Jenkins at Cloudbees jumped in with some hard earned lessons from their experience working on the most widely used orchestration system in history. The Concourse team at Pivotal helped redesign our extensibility system based on what they learned from the successful Concourse resource model.
Then we got to work building it all out! Our goal must have really resonated with others, because we could really feel the power of open source from day one. Even when there were only a few of us working together at Google, we were part of a much larger effort. We really wouldn’t be here today without the help of our contributors, maintainers and governing committee members.
A New Home
Around the time we prepared for our first release, it started to become obvious that Tekton (then called knative/build-pipeline) needed its own home. The knative brand and community helped immensely, but Tekton was meant to provide CI/CD for everyone – not just serverless or even kubernetes users. So in February of 2019, we decided to split out the project, name it “Tekton” and donate it to the newly-forming Continuous Delivery Foundation just in time for the 0.1.0 release.
Kim Lewandowski announcing Tekton at the Open Source Leadership Summit
Open source, governance, and communities are hard. The move out of knative and into a new foundation was a big change for the project, but has proven worth the effort! Tekton still works great with other knative components, but has had the chance to grow its own community and evolve to a spot that its users need. Thanks to the community, Tekton has expanded into multiple projects like the Dashboard and CLI, and in Tekton Pipelines we have been so lucky to gain the expertise of folks like Vincent Demeester and Andrea Frittoli.
The rest of this year has felt like a blur, but I wanted to call out some major milestones we hit:
March – The first Tekton Pipelines release (v0.2.0) using Tekton itself!
June – First release of the Tekton CLI!
July – The first Tekton Pipelines release (v0.5.0) by a community member not at Google!
July – Tekton Friends repo created!
August – First release of the Tekton Dashboard!
September – First Triggers release!
October – Tekton passed 100 contributors in October!
What’s Coming Next?
We’re rapidly approaching the first Tekton beta release! As part of this effort, we evaluated our API surface and identified quite a few areas that need hardening. This includes finishing up the table-stakes requirements for a CI/CD platform – things like triggers, metadata storage and building up our catalog. The Triggers v0.1.0 release has made Tekton usable in so many new ways, and we’re just getting started there still!
Scott Seaward has has just started work on refactoring PipelineResources into an extensible system that will form the basis for the Tekton catalog, and Jason Hall is working on a metadata storage system that will help power some new ideas around software supply chain management.
If you’d like to get involved in the Tekton project, you can find us on Github, Slack or our email list . We’ll also be at Kubecon next week! Come attend one of the many sessions or the CD Summit. Here’s to Tekton in 2020!
Written by Tracy Miranda, CloudBees director of open source community and member of the CDF governing board
The CD Foundation (CDF) recently shared its 9 Strategic Goals. The second on the list is “Cultivate Growth of Projects.” This goal naturally leads us to ask ourselves the question: how do we measure the growth of our projects to know we are being successful?
There are many dimensions to open source projects. In order to sustain a project much more than code is required. The CDF helps with multiple essential services for project growth and sustenance. One of my favourite services is the CDF devstats site, which provides a wealth of data around the projects. CDF devstats, which is based on the CNCF devstats, gives indicators on community health and contributor statistics.
Example from Tekton, one of many dashboards and data sets available:
Sometimes we have distorted views of how well projects are doing – this can be down to a few things such as hype or public sentiment around a project. Sometimes newer projects are viewed as doing better than older projects. It is important to have a sense of how well your project is doing. While there are lots of different ways to do it, one method I really like is looking at the number of individual developers contributing to a project.
With CDF devstats I am able to take a snapshot of that data, and then see how the CDF projects stacked up against CNCF graduated projects.
The chart here shows a visualization of average developer contributions to each project based on data from the past one year. There are many caveats with the data. E.g. Which repos are included for each project may not be strictly equivalent. But what I like about it is that at a high level it gives an indication of the size of project contributions and how projects compare relatively.
I also like that it is all open – so you can verify the data and process for yourself, plus do your own analysis.
Kubernetes, as you might expect, is a powerhouse of a project with thousands of contributors. But actually Jenkins stacks up nicely in comparison with a healthy number of contributions – which is all the more significant considering it is a 15 year old project. Sustaining and growing community contributions year-on-year for 15 years is an incredible achievement. The other CDF projects, Spinnaker, Jenkins X and Tekton, are much newer but also coming along quite nicely. See this repo for links to data.
For me this is a nice snapshot to say we’re off to a good start here at CDF. Individual project growth will come down to each project’s community – but CDF will be working to provide key services and some of the less fun grunt stuff so project leaders can better focus on the important efforts of community building.
By Tracy Ragan, CEO DeployHub, Inc. and CDF Board Member
Good news! The CD Interactive Landscape has been made public by the CD Foundation. You can find it at https://landscape.cd.foundation/.
What is an interactive landscape? The concept started when the CNCF began the process of cataloging different types of tools for building out a cloud native architecture. This led to the creation of the CNCF Interactive Landscape. Turns out this tool became very helpful to all of us sorting out this new and exciting modern architecture. In the interest of providing a similar reference, the CD Foundation defined their own version of the interactive landscape to help clarify the tools needed to adopt a fully automated CD process.
Who is the CD Foundation? The CD Foundation (CDF) serves as the vendor-neutral home for many of the fastest-growing projects for continuous integration and continuous delivery. The concept of the CDF was started by CloudBees and quickly accepted by thought leadership companies such as Google, CapitalOne, CircleCI, JFrog, IBM, Netflix, Salesforce, Huawei, DeployHub, Armory, WhiteSource, GitLab and others.
Why is the CD Interactive Landscape important? In today’s hybrid environment of both legacy and modern development platforms, there are hundreds of tools that help streamline the movement of code from development through production. There is a misconception that there is such a thing as a continuous delivery solution. However, according to the CDF, CD is defined as:
“CD is a software engineering approach in which teams produce software in short cycles, ensuring that it can be reliably released at any time. The rise of microservices and cloud native architectures has caused a corollary rise in continuous delivery practices. This is related to CI/CD that includes Continuous Integration (CI) — the practice of merging all developer working copies to a shared mainline several times a day.”
One of the primary goals of the CDF is to help drive the adoption of this practice. The practice relies on a set of tools to orchestrate, automate, configure, track and secure the Continuous Delivery approach. The CD Interactive Landscape is a tool for understanding the roles of each solution as defined by their core competency.
The CD Interactive Landscape is not a static document. It is intended to be expanded upon by the community of open source projects and commercial solutions that make continuous delivery possible.
This first version of the Landscape was created by members of the CDF and reviewed by the CDF Technical Oversight Committee (TOC) led by Kohsuke Kawaguchi – the creator of Jenkins and JenkinsX. This is not the end of our story. We are asking that the broader community, members and non-members of the CDF, begin updating the CD Interactive Landscape with new sections and tools, or even correct where a solution fits in – we could have gotten this wrong and apologize in advance if we did.
Written by Tracy Miranda, CloudBees director of open source community and member of the CDF governing board
The CD Foundation is about 6 months old and many of the early days have been spent discussing where we will as a community focus our efforts over the next year. CDF is in a unique position as a vendor-neutral body at the heart of an industry rapidly figuring out how to deliver software better and faster. With that in mind it was important to the governing board to come up with specific goals where we should focus our efforts.
The CD Foundation governing board went through a very collaborative process to figure out what these should be. This included speaking to those who already have a lot of experience in the CI/CD space. A personal highlight of the process for me was a face-to-face at DevOps World where we had the honor of getting feedback from Jez Humble, co-author of the Continuous Delivery Book itself and Jayne Groll, Head of the DevOps Institute.
CDF Board Brainstorm session at DevOps World | Jenkins World August 2019 (Photo credit: Tara Hernandez)
After many discussions, the Governing Board agreed and ratified the goals in early October. Here is the list of the 9 strategic goals that will map to specific initiatives in our program plan for 2019/2020.
Drive continuous delivery adoption
Cultivate growth & adoption of CDF projects
Foster tool interoperability
Champion diversity & inclusion in our communities
Foster community relations
Grow the membership base
Create value for all members
Promote security as a first class citizen
Expand into emerging technology areas
These goals are shared in no particular order or ranking. These goals are also not static every year and meant to evolve over time with input from the community. There is a lot to say about each goal including why each one matters, not just to the foundation but also to the wider CI/CD community. Over the next few weeks I will share a post on each goal and go into the why, what, how, where & who. Plus I’ll also share details of how you can join in to help us meet those goals!
Outreachy is a program for open source internships that specifically targets people in demographics that are underrepresented in tech. Since 2010 Outreachy has had over 400 participants making contributions to open source projects. Outreachy is one of the most effective programs for improving the diversity of open source communities. For those familiar with Google Summer of Code, Outreachy follows a very similar format.
The Continuous Delivery Foundation is a neutral home for the next generation of continuous delivery collaboration. We know that the greater number of diverse voices we have collaborating, the more effective we are as a community. Which is why we are thrilled to be participating in Outreachy for this upcoming round.
Three of the CD Foundation projects: Jenkins, Jenkins X and Tekton are offering Outreachy internship projects. The Jenkins project has participated in the previous 2 rounds of Outreachy, having a total of 4 Outreachy interns working with the community on the Jenkins Audit Log Plugin. Jenkins mentor Matt Sicker shares in this post “Outreachy has helped open my eyes to the struggles that developers from around the world are dealing with which can be improved upon to help expand our communities. For example, many countries do not have reliable internet or electricity, so the use of synchronous videoconferencing and other heavyweight, synchronous processes common to more corporate-style development are inadequate in this international context.”
In that way Outreachy is also beneficial to the mentors participating. The actual tech contributions are a bonus side effect. Jenkins participates in the program with no expectation that the interns remain part of the community – but takes a wider, long term view that this generally improves open source and tech communities as a whole. Tracy Miranda, Outreachy coordinator for the Jenkins project says “As of this year I know of 2 Outreachy alumni (non-Jenkins projects) who were hired by my employer and both mention the Outreachy program as an important stepping stone in their career journeys.”
Here are the details of this round’s CD Foundation projects which we are looking for interns for. Please help us spread the word.
Kara de la Marck, the Jenkins X Outreachy coordinator can personally speak to the benefits of the program: “Outreachy is a fantastic mentoring program that helps to onboard new contributors to a project and to open source more generally. Many participants go on to become long term contributors to open source. As an alumna, I have carried forward a deep appreciation of open source as an enabler of global collaboration, technological innovation, and community. I’m incredibly happy to welcome Outreachy participants to Jenkins X.”
Please help us spread the word, and we look forward to working with Outreachy interns and welcoming them into our community.
Hey everyone, I am excited to announce the formation of the Security SIG – the CD Foundation’s first Special Interest Group (SIG)! The Security SIG began as a lightning talk at the first CD Summit in Barcelona this past May, and progressed to a formal proposal in August. In September it was adopted by the Technical Operating Committee (TOC).
The charter for the Security SIG is to provide a neutral home for discussion around designs, specifications, code and processes to enable security across the software supply chain. Topics of interest include the following:
Observability – enabling actions performed while writing code, compiling, testing, and distributing software to be manifest and verifiable.
Policy – enabling consumers of software to specify and implement policy over consumed software.
Inventory – enabling administrators to inventory and audit software used within their organizations.
Runtime Security– enabling detection and prevention of software tampering at runtime.
Vulnerability Communication – providing mechanisms for breaches in the integrity of software to be communicated and remediated.
Vulnerability Recovery – providing mechanisms for consumers to recover from compromised or untrusted software.
Membership in the Security SIG is open to the public. Here are some details:
CDF is an open source technical community where technical project collaboration, discussions, and decision-making should be open and transparent. Please see our CDF TOC principles, for more background on CDF values.
Design, discussions, and decision-making around technical topics of CDF projects should occur in public view such as via GitHub issues and pull requests, public docs, public mailing lists, conference calls at which anyone may participate (and which are normally published afterward on YouTube), and in-person meetings events. This includes all SIGs, working groups, and other forums where portions of the community meet.
This is particularly important in light of the Linux Foundation’s Statement on the Huawei Entity List Ruling. (Note that CDF is part of the Linux Foundation.) Our technical community operates openly and in public which affords us exceptions to regulations other closed organizations may have to address differently. This open, public technical collaboration is also critical to our community’s success as we navigate competitive and shifting industry dynamics. Openness is particularly important in any discussions involving encryption since encryption technologies can be subject to Export Administration Regulations.
If you have questions or concerns about these guidelines, I encourage you to discuss it with your company’s legal counsel and/or to email info@cd.foundation.
We are thrilled to announce that Jenkins X will be joining the Continuous Delivery Foundation as one of the founding projects. The Continuous Delivery Foundation (CDF) is a brand new sub-foundation of the Linux Foundation and will be dedicated to advancing the practice of continuous delivery and nurturing an ecosystem of interoperable tools for software delivery.
Jenkins X is just over a year old but has been growing rapidly as the CI/CD solution for modern cloud applications on Kubernetes. Jenkins X automates CI+CD for Kubernetes using the best of breed OSS tools such as Jenkins, Tekton, Prow, Skaffold, Kaniko and Helm. The CDF will be a sibling foundation to the Cloud Native Computing Foundation (CNCF) which hosts Kubernetes amongst others. CDF will have its first event, CDF Summit, on May 20th alongside KubeCon Barcelona. We always love to work closely with other communities, and this will continue at scale within the CDF.
“I’m really excited to see the formation of the CDF – it’s starting with some of the most popular best-of-breed open source tools in the CI/CD space,” said James Strachan, co-founder of Jenkins X and distinguished engineer, CloudBees. “I’m looking forward to increased collaboration between us all to help accelerate the open source CI/CD landscape.”
Jenkins X started life under the Jenkins umbrella. In CDF, Jenkins X will be a distinct project from Jenkins which means some changes, such as having a Jenkins X Technical Steering Committee. These changes will happen gradually as we transition to CDF over the coming weeks. Normal development work will continue as usual.
We are excited about all the new possibilities that being part of the CDF will bring. We look forward to new initiatives and welcoming everybody to get involved with the project.
Jenkins contributors have decided that our project should join this new foundation. This discussion happened over the time span of years, actually, but a relatively succinct summary of the motivations are here.
Now, as an user, what does this mean?
First, there will be no big disruption/discontinuity. The same people are still here, no URL is changing, releases will come out like they’ve always been. We make the decisions the same way we’ve been making, and pull requests land the same way. Changes will happen continuously over the period of time.
This is yet another testament to the maturity and the importance of the Jenkins project in this space. With a quarter million Jenkins running around the globe, it’s truly rocking the world of software development from IoT to games, cloud native webapps to machine learning projects. It makes Jenkins such an obvious, safe choice for anyone seeking open heterogeneous DevOps strategy.
The CDF creates a level playing field that is well-understood to organized contributors, which translate into more contributors, which results in a better Jenkins, faster. Over the past years, the Jenkins project has been steadily growing morestructures that provide this clarity, and this is the newest step on this trajectory.
Any serious dev teams are combining multiple tools and services to cover the whole software development spectrum. A lot of work gets reinvented in those teams to integrate those tools together. Jenkins will be working more closely with other projects under the umbrella of the CDF, which should result in better aligned software with less overlap.
Our users are practitioners trying to improve the software development process in their organizations. They get that CI/CD/automation unlocks the productivity that their organizations need, but that’s not always obvious to their organizations as a whole. So our users often struggle to get the necessary support. The CDF will advocate for the practice of Continuous Delivery, and because it’s not coming from a vendor or a project, it will reach the people who can lend that support.
So I hope you can see why we are so excited about this!
In fact, for us, this is an idea that we’ve been cooking for close to two years. I don’t think I’m exaggerating much to say the whole idea of the CDF started from the Jenkins project.
A lot of people have done a lot of work behind the scene to make this happen. But a few people played such instrumental roles that I have to personally thank them. Chris Aniszczyk for his patience and persistence, Tyler Croy for cooking and evolving the idea, and Tracy Miranda for making an idea into a reality.
