 Hello everybody. Good morning, good afternoon, good evening wherever you are joining us from. I'm Tracy Miranda. I'm the Executive Director of the Continuous Delivery Foundation and I'll be on hand for the next 20 minutes to answer any questions you might have about CICD or DevOps or anything. I'm coming to you from Ottawa Canada where it has incredibly just started snowing. So I make that 169 days we've had without snow. So to distract me from the cold weather, please keep your questions coming in and I'll be happy to answer those. So if you aren't familiar with the platform, we have a Q&A tab over to the right by the chat and you can go ahead and drop any questions inside there. And while you are doing that, I want to highlight some news I've just seen today. So there's a new open source job report that came out and this is talking about you know what hiring managers are looking for and one of the key things that that report pointed out is that there's been a huge spike in demand for DevOps job. So from all the different areas people are definitely looking for folks who have experience with DevOps tools and practices. So that's certainly consistent with what we're seeing at the Continuous Delivery Foundation that there's a really high demand. There's a much much greater appreciation that delivering software has become a huge differentiator for any sort of company, whether you're a bank or a retail business or a software company, it doesn't make a difference. You need to now differentiate through software and the folks who can make this happen, who can deliver software effectively are the DevOps folks. So yeah, not surprise. It's an amazing area to be in. And further than that, the report goes on to say that open source jobs, like folks who have experience with open source, there's actually a dearth of them. So a huge demand for people who are who have the open source skills who get engaged with projects. So what I'm going to do is just talk a little bit about the Continuous Delivery Foundation and what our role is in the whole DevOps ecosystem. So the Continuous Delivery Foundation is an open source foundation and it's the home to some of the most popular and fastest growing projects for continuous delivery. So many people have heard of Jenkins. There's Jenkins and Spinnaker. Those are two projects very widely adopted for CI and CD. And then you have the projects which are newer in the space tackling problems around cloud native. So this is Tecton and Jenkins X. Okay, I'm going to interrupt. So we have a question which I will answer live and it says what defines DevOps as a job spec? Okay, so I think for when we talk about DevOps jobs, I think there's definitely different camps of how people see this. So there's often controversy around this because when we think about the original definition of how DevOps came to be, it was all about breaking down silos between the dev side of the house who traditionally perceived as tossing the code over to the ops and then the ops who would then deliver that. So if you think about DevOps as a culture, then perhaps DevOps as a job spec doesn't make a lot of sense. Nevertheless, I think over time the term DevOps has evolved and correctly or incorrectly, it stands to present that whole set of practices which kind of evolve from the upside but relate to all the tools there. So depending on your perspective, some people will take a kind of more pure idea of DevOps where the DevOps team is actually the team who are in place to help the dev folks integrate with ops and kind of be those bridge builders where others take a more simplified view where DevOps tends to be kind of this umbrella for how to use tools, whether it's Jenkins or Spinnaker or Terraform. So we see that DevOps used in both those ways. In particular, I don't want to get caught up in too much like which one is right or which one is wrong. I think it's useful if many people use it in a common way to use it that way. So I think DevOps is just focused on the delivery of software and a role where you want to break down barriers and work with the tools to get the software delivered. So yeah, I think depending on where you go, you might see different definitions from everything from ops tooling to a more higher level. Interestingly enough, we're chatting with some folks at the Continuous Delivery Foundation. We have a working group focused around interoperability and we also have conversations there about being better about defining things so we can avoid some of this confusion. And one interesting trend that's emerging there is in the past, we've seen many companies have had teams that they specifically call DevOps. And this is kind of, some people this is a bit problematic because if the idea is to break down silos between different teams, then setting up a new team called DevOps perhaps doesn't match that ethos. But what we are starting to see is first, we saw lots of companies set up DevOps team as their way of saying, okay, we're going to focus on this. Then as they mature or things evolve, then they find that actually they might rename those teams to better reflect what they're doing. And one great example we had was a company called Ghostpot Check. And they are renaming their DevOps team to be cloud ops to better reflect that actually what this team is doing is managing the operations and the interaction with the cloud, everything from kind of the account management to the scaling and to adopting different technology. So I think that's an interesting trend we'll see more about. Okay, so I hope that answers that question. And if you want to do any follow-ups, please just let me know. Okay, another question that's come in is, what is the difference between continuous integration, continuous deployment and continuous delivery? So that's a great question because we do get a lot of conversations in the community discussing this. And it is a point of contention because different people again see the definition differently. And the reason that could be a problem is if you're talking at cross-purposes with someone else or it leads to kind of a misunderstanding. Now continuous integration, continuous integration, I think that is pretty how we see that is, that is where developers or practitioners are constantly committing code and it's being built. I don't want to use the word integrated, but it's being whatever the process is to bring it into the mainline, the tests are being run. And it makes sure that your working copy is always up to date. And this is as opposed to once upon a time where integration would only happen as a big bang effect. So the continuous is important. So you typically want that to happen once a day. And so you're avoiding the situation where code gets committed once a year or things like that. Now on continuous deployment and continuous delivery, I think these terms get used interchangeably. Personally, I think it's really important that continuous delivery represents the entire set of practices that you must undertake to keep your code in a state where you're ready to deliver. So I'd like to see it more defined as an engineering approach or even a discipline. But oftentimes people narrow that definition and they use it to reflect kind of just the deployment stage of the pipeline. So then continuous delivery and continuous deployment get mung into the similar thing where continuous deployment refers to actually getting your code out into production and all the stages that lead up to that. So some places you'll redefinitions and they will just say deployment and delivery only have the slight difference. But really, I think you need to see delivery as the overall set of practices, which does include continuous integration, continuous deployment or automated deployment. And it does include other things as well. So testing, security, test data management, and one of the great places like the Accelerate book by Nicole Forsgren and others, I think that kind of gives an overview of how meaty continuous delivery is. And it breaks it down into these eight different capabilities. So I personally like to separate that where continuous deployment can refer to just kind of the automation deploy, things that you're pushing things between environments and finally out to production. Okay, let me find a way to mark the questions as answered. Okay, so I don't know if we've got some support. I see the question and I can't seem to answer one of I can't seem to market as answered live. So just I will try and figure that out. Okay, so the next question we have coming in is which tools can I use for CICD so continuous integration or continuous deployment and delivery. So this is kind of a big question because it really depends. But I want to give you some indicators as to how you can go about thinking about, you know, what tools do I use? Now traditionally, you know, one of the defining tools for this has been Jenkins and almost everybody has in some way or the other used Jenkins. Now Jenkins, while we often think of it as a CICD tool, it really is much more powerful and much more flexible than that. So it is Jenkins is the ultimate sort of automation server, and it is really, really amazing. Its sweet spot is for continuous integration. So that is kind of where the initial growth in Jenkins used, it helped kind of define, just helped lots of people to manage their CI in the early days. And then it built on that and it involved to have pipelines, which would help you actually deploy the code. And in fact, now these days, we have a lot more people using Jenkins pipelines than Jenkins kind of free form jobs. But if we go beyond that in recent years, the whole landscape has really exploded and we've had a lot of different kind of tools come in. And one of the key drivers for this has been the emergence of cloud native technologies. And what the difference with cloud native to what was there before is that you have this real strong distributed model, which allows endless scaling, like you can scale horizontally, you can scale vertically, and it really is kind of very, very powerful. And the same time as cloud native technologies have emerged, we have a lot of different things changing about how we write and deliver software. So this includes things like the move to microservices. Traditionally teams would work on a single code base, so a monolithic code base, and they would deliver to very few environments. Now with the onset of microservices and cloud native technologies, what we're seeing is now teams delivering software have to contend with many more like locations with the code. It changes what the definition of the application is. And there's a big proliferation of environments to deliver to. And as a result, we have a lot more tools emerging. And I'm going to drop a link to the continuous delivery landscape, which is where we're trying to categorize and kind of set out all the different tools that come together to help you deliver software. And because traditionally we've fallen into this, do CI CD, which leads people to think, I need a CI tool and a CD tool. And that's it. My job is done. It's actually much more involved than that. And it does depend. Are you starting a Greenfield project? Are you looking at cloud native? Are you trying to move something existing? And then you also have options for managed services, software as a service. So the landscape tends to give you kind of breakdown into big overarching chunks, what the different kinds of areas are, and then give you tool suggestions in each one. And then you'll see in some categories, this is broken up by cloud native and traditional. So there's a category there around infrastructure deployments. Now it is an early version of the landscape, so it's pretty new. And we do welcome, it's open source. So we do welcome contributions. So if you have a tool that you're seeing is not there, please feel free to submit a poll request. And we have a few guidelines. And we can add that to it. Okay, I'm going to click that as answered live. Okay, we have another question that's come in. And from Eugene, and it says, what are the benefits to join the continuous delivery foundation? Umbrella for the OSS project, part of being a Linux foundation project. Marketing infrastructure, funding opportunities. Can you please explore this topic? Okay, yes. So I assume this is asking about from the perspective of an open source project. So it's a great question. So why would an open source project choose to join the continuous delivery project foundation? So we are an umbrella foundation, similar to the CNCF. We are a sub foundation of the Linux foundation. So we consider CNCF to be like a sibling organization. And under this umbrella, really where continuous delivery foundation helps the projects is by helping them grow and taking care of a lot of the things that you need for an open source project that can benefit from doing them together. So for example, we offer a whole bunch of services. So we have a technical oversight committee, which brings kind of the leaders of the project together. And then examples of things where we help, okay, so you brought up marketing. That that's a good one. And that ties in a lot to our events. So for instance, we had a CDCon, which we ran two weeks ago, and we had each of the projects there. And we provided a space for folks to come and meet the project leaders. Those were some of the best conversations. So it's helping with that organization of the project. We're also running Hacktoberfest across all the projects. So we bring the projects together, we help promote, we let you know how to, you know, structure your project for Hacktoberfest. It's an amazing way to get new contributors. So bringing in new people through these programs, we also sponsor mentorship through programs like Outreachy, which projects used to increase the diversity of the contributor base. We provide support for Google Summer of Code and upcoming Google season of docs to help improve documentation. On top of that, there's some other fun stuff. The Continuous Delivery Foundation does some logos for projects. If you've ever seen the Tecton project and Tecton Friends, it's got some great logos. So we'll set up logos for each of the projects. We also have a continuous delivery store, which has swag, which I'm going to find a link to this. Okay, I'm going to do that as I talk. So we have a store, which again, we offer to all our projects. We also deal with trademark and licensing issues. So that we find projects, you know, typically they want to focus on the code. So we're doing all the periphery things. Okay, so I hope that answers your question. I think we are out of time, but please feel free, anybody, if you want to follow up with any questions, I'm Timuranda at CD.Foundation. Thanks very much for attending and please feel free to follow up with me and come get involved with the Continuous Delivery Foundation. Thanks, everybody.