 All right, more. So in addition to the GraphQL Foundation, we have another new announcement today, another new project. How many people here are familiar with the concept of DevOps? Where's Chris? Chris, you told me that was like new as of this morning. So continuous development, continuous integration. This is one of the cornerstones of the modern development process. The sort of ability to rapidly create something which I call microservices. I coined that term now. But the ability to quickly create code, test it, and continuously deliver it is something that's really important to modern developer velocity. I mean, the continuous delivery concept has just created huge, huge returns in terms of the speed at which developers can create really, really good code. And to that end, the Linux Foundation is really excited to announce our support for the Continuous Delivery Foundation. This is a collaboration to create a neutral home for Jenkins. Anybody ever heard of Jenkins? Does anybody here use, everybody uses Jenkins. Jenkins X, Spinnaker, and Tecton. These are going to be the cornerstone projects of the Continuous Delivery Foundation. These projects came from various places. We're very grateful to folks like Netflix and Google who are contributing code to this project. This will be a vendor neutral home for the open source projects for Continuous Delivery and specifications related to Continuous Delivery and the release pipeline process. We have amazing folks joining us here today to announce it. I want to bring on to the stage Kosuke Kawaguchi from Cloudbees and the creator of Jenkins who is going to talk to us about the Continuous Delivery Foundation. Welcome. So, yeah, I'm Kosuke, I'm city of Cloudbees and I'm creator of Jenkins. Now, as so many people have said before, every software is eating the world and every business is under tremendous pressure to transform itself into a technology business. Now, those of the geeks in us, and it sounds like you're my kind of clowns, I really love that, but those of us who are in the technology space, we have discovered and then converging to a set of practices that we call the Continuous Delivery. It's the idea that getting the new software in the hands of the users rapidly, safely, and quickly and repeatedly is a key to give the business the necessary agility that makes or breaks the business. And research has shown this to be the case time after time. Some companies who live and breathe this culture day in and day out being so successful that also proves this case in the real world. You know, companies like Netflix and Google who we would like to invite on stage. Now, other companies are also trying to take note of that and they are trying to apply this practice to the way they develop the software, but it turns out that this is not as an easy practice as it should be, so it's not as widely available. So we think it's time to democratize this practice, and this really is a call, a challenge to the industry. So we, the Continuous Delivery Foundation, we answer that call, right? We, the founding members of these foundations believe in the mission and power of the CD, and as a city of the clabbies and creative Jenkins, the clabbies really believed in this mission for the longest time, and that kept me going. So I'm really thrilled that we now have a much bigger group of people working together, and collectively we can make a lot bigger impact. Another noteworthy thing is the presence of the end user companies like HSBC, ATOS and Capital One, and then it's another proof that these companies have noticed that this practice makes a real impact to the way they run the business. And so that's also the part of the force behind this new foundation. Now, through the CDF, we advocate this practice of continuous delivery in the industry, and we encourage practitioners to collaborate across the barriers of companies to move the state of the art forward. And obviously, we are an open source foundation, so we believe in the open source, helping this practice of CD and encompassing the wide spectrum of the social delivery life cycle that's necessary to successfully implement the CD. And so we seek to create a place to foster and sustain thriving open source projects that collaborate and interpret between each other. So that's what the continuous delivery foundation is about, but don't just take my word for it. I'm here with my fellow leaders of this mission together. So here I'd like to invite Kim. She's a product manager from Google Cloud. Please welcome her. Thank you. Awesome, hi everyone. So I joined our DevOps team about a year ago at Google, and I spent a ton of time talking to customers, hearing about their CI CD practices of their organizations, and the challenges that they're up against. So it really brought me back to my engineering days at startups when we were trying to understand what all this DevOps stuff meant anyway. Well, the one thing we could agree on is that we knew if we caught problems in our code early on in its life cycle that we would be saving ourselves a bunch of time, money, and headaches from potential production outages later on. So deciding to practice CI CD was usually an easy decision for companies to make, but the next step is figuring out which tools and best practices to follow. And so when I started looking at the CI CD landscape, I got lost in the sheer number of tools available. And every time I would talk to a customer, they would tell me about some new tool that I had never heard of before. So even at Google, our engineers have a ton of tools to choose from. And so while freedom of choice is great, it can eventually lead to frustration, fragmentation, confusion, and apathy. So and this leads to brittle software delivery processes, and portability constraints, and also security gaps. And as you can see from Kelsey's tweet, lots and lots of bash scripting. So while homegrown solutions are never optimal, it's always the natural outcome of solutions sprawl. And this is why adoption and narrowing focus to supported solutions is so important today. But when you squint at all these tools at their core, even though the terminology differs greatly, they all have a concept of a workflow, a pipeline, artifacts, source code access, build results, and more. But the end goal is always the same. Get my code from source to production as quickly and securely as possible. And so at Google, we took a step back, and after a few brainstorming sessions, some whiteboarding, we asked ourselves if we could do the same thing to CI CD that Kubernetes did with containers. That is, could we collaborate with industry leaders as a broader community in the open to define a common set of components and guidelines for CI CD systems to build and deploy code anywhere, whether that be mobile, on cloud, VMs, your sneakers, anywhere. Next slide, please. And so this is how Tecton was born. Tecton is a shared set of building blocks for building CI CD systems. So when we heard about the continuous delivery foundation from CloudBees and the Linux Foundation, we got super excited because it really aligned with our vision of Tecton and our goal to help developers modernize on their path to cloud and software delivery best practices. And now I would like to introduce my engineering teammate and lead on the Tecton project, Christy Wilson. Hi everybody, I'm Christy Wilson. I'm a software engineer at Google and I'm really passionate about software quality. Throughout my career, I've always ended up gravitating towards work that has to do with CI CD. And maybe one of the reasons for that is that everybody needs CI CD. So before you can try to apply fancy modern development practices like chaos engineering or progressive delivery, you have to start with CI CD. If you want your projects to scale, if you want to sustain growth, if you want to grow your open source contributor base, you have to have CI CD. And regardless of the size of your company, whether you have thousands of engineers or you're a startup, whether you're working on Greenfield or you're maintaining legacy software, you have to have CI CD. And with the technological shifts that we're seeing right now, CI CD has this really cool chance to take a huge leap forward. Specifically, if we can center our CI around containers, dynamically orchestrate those containers, and use serverless methodologies to control our resource utilization. And then imagine if we can package all of that in well-defined conformant APIs so that users can have all that power without being locked in. And that's what Tecton Pipelines is all about. So Tecton Pipelines is a CI CD solution where containers are the most basic building block, and then you can combine those containers together to make complex pipelines. Now we implemented this by extending Kubernetes, but the API spec itself could be implemented by any vendor, whether they're using Kubernetes or not. And this is a collaborative effort. So right now we have regular contributions from many companies, including Google, CloudBees, Pivotal, Red Hat, and IBM. And as of today, Tecton Pipelines is integrated with Knative, with TriggerMesh Actions, and thanks to CloudBees support was recently added to Jenkins X as well. But that's just the beginning. With the CDF, we're looking forward to collaborating with a community that's focused on CI CD so that we can keep this going. So that an engineer can go to a project, take the entire CI CD pipeline, and run it against their own infrastructure. Or they can take pieces and run them in isolation and reuse them. And the more vendors support Tecton Pipelines, the more choices users will have. And eventually they'll be able to take features from multiple vendors and put them together with one pipeline. And so that's what Tecton Pipelines is all about. And now I'd like to introduce Tyler to talk about Jenkins. Thanks. Howdy, everybody. I'm Tyler, I'm from the Jenkins project, and I can't tell you how excited I am to be here. The Continuous Delivery Foundation was an idea that started at a Jenkins contributor summit almost two years ago. And last year that idea evolved at the Open Source Leadership Summit in Sonoma. I don't know how many of you were able to join. And now it's become this really amazing collaboration between all these different companies. So I hope you get a lot of good work done here today. There's a lot of opportunities for us to do something interesting. And I look forward to hearing about it at the 2020 Open Source Leadership Summit. So I don't doubt that many people understand what Jenkins is, but just to give you a high level overview, Jenkins is an open source automation server. And the reason we branded ourselves as the sort of automation server is when Jenkins started out, it was really just about continuous integration. And then we started to see that people in operations were using Jenkins. And as the industry has moved forward, we found that people are using Jenkins for continuous integration, for automated tasks, all the way up to continuous delivery pipelines. And to me, that's a really strong testament to the power of extensibility in Open Source that the Jenkins project embodies. And if you're curious what Jenkins looks like today and sort of what all of those contributions have led to, we've got this really, really rich ecosystem of plugins and tools around Jenkins to make it very, very usable and understandable as many people that are involved in the software delivery process at a company. And with all of this innovation that we've experienced over the past couple of years, we've started to really see pipelines and continuous delivery as the new frontier of what we need to be focusing on. And so this opportunity to work with a lot of other organizations on pipelines and the concept of that continuous delivery process is really exciting. But the Jenkins project, and I really want to hammer this home, is not just a technology thing. The Jenkins project, for me, I've been around for 10 plus years, it's been quite a while actually, is a great group of people all the way from committers like Chris and Andrew and Evelina that are trying to push the Jenkins technology in different ways, whether it's on pipeline or mobile or configuration as code, all the way to advocacy and marketing contributions from people like Alyssa or Heidi that have helped make Jenkins user conferences, Jenkins area meetups, and all of the other great advocacy work that we have going on in the Jenkins project, a reality. And we're very lucky in that it's not just been people, it's been all of these organizations from the Oregon State University open source lab to CloudBees, which has funded such a tremendous amount of development and innovation to companies like Microsoft, which partnered with us for our infrastructure, which runs right now on Azure, to so many other organizations that believe in Jenkins and believe in the future of continuous integration and continuous delivery. And that's really what has me excited about the continuous delivery foundation is taking what we already had going fairly well in the Jenkins project. We've worked very hard to make it successful and then bring that up yet another level with even more collaboration and more investment from all of these great companies across the software development ecosystem to improve not only Jenkins, but the continuous delivery space at large. And what Christy alluded to is one of the things that I'm incredibly excited about, this idea of shared concepts for what pipelines mean across these different products and across these different tools that people leverage to implement continuous delivery processes. And so that's all I wanted to share with you from Jenkins. I'm very, very happy to introduce someone who has worked on one of those products I look forward to pipelines being integrated with, Andy, who works on Spinnaker from Netflix. Come on up, Andy. Thank you. Thank you. Netflix set out to build Spinnaker because speed is a differentiator for any business. Continuous delivery is the means for businesses to thrive in today's fast-paced world. If a business cannot rapidly, reliably, and safely deliver value to its customers, it will be disrupted by one who can. Since launching Spinnaker in 2015, we've seen growth span the gamut from delivery metrics to community to innovation. In short order, after we released Spinnaker internally, we saw deployments into AWS double from 2,000 a day to 4,000 a day. But that metric didn't capture the true value that Spinnaker was providing to a wide variety of end users. So today, our key metric at Netflix is running pipelines, which is at 30,000 a day in climbing. We've seen the Spinnaker community grow from just one company, Netflix, to hundreds of enterprises around the globe. And the innovations that have blossomed both from internal contributions at Netflix and external contributions from the community have pleasantly surprised many of us. It's because flexibility and plugability of a delivery process has unleashed unprecedented developer productivity at Netflix and at other enterprises. Not only do we at Netflix use Spinnaker to deliver containers and VMs rapidly and safely to myriad environments that span the globe, but Spinnaker is also leveraged to deliver firmware updates to our content delivery network. Development teams across Netflix use Spinnaker to deliver libraries as well. And finally, Spinnaker's pipelines facilitate the safe rollout of runtime properties and feature flags. Spinnaker powers the delivery of every aspect of the Netflix product that hopefully many of you enjoy tonight. The chance to share our many lessons learned and to learn from a community laser focused on continuous delivery is an opportunity we couldn't pass up. And we're thrilled at the prospects of taking continuous delivery to the next level and to a wider audience of practitioners. And with that, I am tremendously happy to introduce Tracy, who's gonna talk about Jenkins X. Okay, can you hear me now? Yeah, brilliant. Okay, so Jenkins X, it's the CICD solution for modern cloud applications on Kubernetes. And software delivery is a team sport. There's just like a ton of research that says high performing teams automate their CICD and use the cloud well. So using the cloud well means today using Kubernetes as the default operating system of the cloud that runs on-premise, public cloud, private cloud or hybrid, and Jenkins X supports all these different flavors of Kubernetes. So whether you are writing new cloud native applications or maybe you're migrating existing applications and you want it to run in a containerized, orchestrated cloud native environment, then Jenkins X can help you by providing like pipeline automation, built-in GitOps and preview environments. Actually, preview environments are the one feature that get developers really excited, this sort of eyes really light up. That's because every time you do a pull request, then a dynamic preview environment is created so you get to review your feature before it's merged. So this like makes all the difference to like shipping code faster without having to worry about breaking things. And one of the reasons that Jenkins X can provide such features, like the project has only been around for just barely a year, is that it really, it builds on sort of this best of breed open source projects. So projects like Kubernetes, Jenkins, Helm, Proud and most recently Tecton, as we saw from Christie. And we see close community collaboration as the key to our success. So we're really looking forward to with the CDF working with other open source communities, particularly the cloud native compute foundation, so CNCF, which is the home of Kubernetes. So much so that our very first event will be the continuous delivery summit, which will be co-located with KubeCon Barcelona. So we'll be there with, was it 12,000 other people? But confined us. But yeah, the whole thing with DevOps, it's not just about tools. So there's this whole aspect of best practices and team culture and attitude, you know, all the really easy things. So we really care about having the space where we can bring people together, focus on these aspects and grow together. And you know, we're looking forward to doing some exciting things, like having some focus on CD for specific areas like finance and embedded. So really hope you can join us for that event. And of course, at that event, you'll hear all about our four founding projects. So Tecton, Jenkins, Spinnaker and Jenkins X, and also about our vision to get these projects integrated and really working together in a way that provides, you know, a cohesive CICD that has our users in mind. It's not gonna be easy, but I do promise it will be fun. So yeah, you're welcome to come join in. And if you wanna keep up with what's gonna be happening with the Continuous Delivery Foundation, please check out our website, cd.foundation, or follow us on Twitter, or really come and talk to any one of us who've been here around this week. We would love to welcome you to join the CDF, which is the Community Building the Future of Continuous Delivery. Thank you. Thank you. Thank you very much.