 Alright, so welcome to our second tutorial for the Q2 hackathon and it's a pleasure to have Jason Lenny, one of our team members from from the product management team. So I guess Jason without any further delay, I'll let you introduce yourself and and let you introduce your topic. Sure. Thanks Ray. So very excited to be here. Very excited to be part of the hackathon and see what everybody comes up with. And yeah, I'm a product manager here at GitLab. And my whole career has been in continuous integration, continuous delivery, release management, that sort of operational planning execution side of things. And so here I'm the product manager for CI-CV. And today I want to talk a little bit about our release stage. Overall within CI-CD we have free stages we have verify package and release verify is the CI automation pipeline and testing side of things packages things like deploying your MAVEN packages or any kind of like binary dependencies and management of that sort of thing. And then the release stage, which is all about the actual delivery of your code to your customers. And there's a number of different categories that I'll talk about in here. Overall, yeah, it's you've built your code, you've tested it, and now you're ready to start rolling it out to your customers. We have a page here about.gitlab.com slash direction slash release. And actually if you go up on you'll see that there is all of those different stages I was talking about here. They all have their individual pages that are going to look a lot like the one that I showed you here, where it talks about what the kind of category content is from a very high level or the stage content. What our north stars are. So these are the strategic things that we're thinking about and working on delivering this here. In this case, using auto DevOps to be zero touch delivery make to do things like once you're building and pipelines are are complete and successful, that we can just take that package that you built and automatically figure out how to deploy it to your Kubernetes environment or whatever cloud environment you're using. So some of the epics that are associated with this are making CD more reliable and simpler. A lot of what I was just talking about managing stability and master easier. So this is things like making sure that pipelines aren't failing that we can help before you do that commit and to master to make sure that things stay green. And reporting in CI CD super important, obviously, a be testing using feature flags. One of the big things that we're doing at a high level here is something called progressive delivery. It's an interesting concept that sort of evolving from the continuous delivery ideas that came from the little continuous delivery book that I have back in my shelf back there. It's using feature flags. It's using get live review apps. It's using tracing for monitoring and tying all these together in a way that isn't really groundbreaking on its own per se. But when you tie all these together, you get a incredible amount of performance that you wouldn't have achieved in any other way. So feature flags is a big part of that feature flags is a big part of the North stars for release and a be testing incremental rollouts using feature flags is tied to that as well. Environments is also part of the release stage. So making environments easier to use and manage certificate handling is sort of just making it easier as well, but making environments easy to provision, making review apps easier to use is a big part of that. Because in general, this is all about the steps that people you might think of like release managers who are doing all of the tracking and administration of making sure that different things are passing and different dates are happening are all implemented within get them. And that they're all actually done in an automated way rather than by having somebody go around with it. Things are done. So these are the categories that are part of the stage. Each of these also has its own vision with details about what we're implementing there, how we're thinking about the category, what the maturity level of the category is where we where it is now in terms of how usable it is and then where what we need to do to take it to the next level. So all of that's documented inside each of these categories. I'll give you a brief overview of what each of the categories are and then we'll take a look at a couple of the ones that might be most interesting to contribute to. The next delivery is all about that automation that takes the built code, the tested code and deploys it to production. So it's not worried about environments. It's not worried about anything like that is just actually doing the important delivery step. So incremental rollouts as part of this things like canary deployments, you know, AB deployments, all of that stuff is part of our continuous delivery category. The release orchestration is all about what the release managers I was talking about were doing and making those things that they were doing manually in the past or with Excel files or clipboards, building that into GitLab and making it all work, you know, in an automated way that's effective for developers and it's also auditable and manageable by the company. GitLab Pages is a tool that lets you create websites from within GitLab that if you create a project and its pages enabled then it will publish the content that's checked into your repo automatically and you can build little websites with this. For our release context, it's used for publishing things like results of the testing or other web type artifacts that are part of a produces a byproduct as part of a pipeline. Review apps is a really cool feature and something that's really unique to GitLab. Review apps are where GitLab, based on just the way your product is configured, your project is configured in the content in it, we will automatically create an environment, deploy your code into it, spin it up, tie it to the merge request that you're working on and let you interact with it and basically have an on-demand environment that's automatically created for every merge request that you're working on. It's super, super valuable. It's really a game changer and we're working on some features there to do automated acceptance testing as part of the review apps. So you can imagine if the merge request spins up a review app and then you go over to the review app, what we're going to add is a panel where you can add feedback right in there and that will automatically end up in it back in the merge request. So that's a really cool feature and it could be pretty fun to work on. Incremental rollout again is tied to the continuous delivery one, we sort of touched on that. Future flags also tied to progressive delivery and how we are going to enable teams to do incremental rollout in a controlled fashion. If you're really interested in this topic, I would recommend checking out the progressive delivery content that we've written on the CICD fraction page. But overall, you can think about it as a developer, there's a number of different stages that you go through as you're releasing. You've got the initial stage where maybe you just have your own personal test environment, then you invite a couple of other developers or maybe a product manager or somebody else who's a stakeholder on the issue and just they can privately look at it with you, then you might start rolling this out to production. You might start doing it with a feature flag where only people who have a company email address can interact with the feature and everybody else just sees whatever else is out there. Then you might start rolling it up 10, 20, 30%, all of that can be enabled by feature flags. Release governance is about collecting evidence about what's happening during the release. So if you think about from the time an issue was created and then somebody does some analysis on it, it's tied to a milestone that's going to be delivered. That milestone is then tied to a release. There's this whole chain of events that happened that ended up being a large release that went out to production. Audit teams and compliance teams and large organizations are really interested in all of that data so that they can do auditing effectively. Because GitLab has the single application that bridges everything from A to Z, we can collect all of that very, very effectively. So our vision for release governance is about that. Secret management is our newest category for release and it's a really, really exciting one. What we're planning on doing here is integrating with Vault and KMS and AWS secrets management and making it easy to store CIC variables inside of one of those more secure repositories. But even going beyond that, storing GitLab's own secrets like GitLab's key that it uses to access our internal database within one of these key stores. And then also providing or just exposing that through GitLab for any developer who wants to store any secret that's related to development. So you'll be able to interact with the GitLab workflow and have secrets management built in using and backed by one of these very, very solid tools that's out there in the market today. So yeah, those are the categories. We'll come back to that. I do want to touch on this contributing section, which is in I think all of the direction pages, three pages. There's quick links here, which I'll open up for where you can go to start finding things that might be interesting to work on. There's this contribute for prize one where we offer a prize, and you can find more details on that on this link with the code contributor programs to see if there's something here that you want to contribute to. These have been selected as being really, really valuable for our customers for us and deliverable. So it's a great place to start. We also have accepting merge request. As you can see, there's a lot more of these. So this this tends to get applied more broadly and it's there could be things that are easy to develop in here. There could be things that are quite complicated. If you see that something is already scheduled for an upcoming release, that doesn't mean we don't accept merge request on it. So feel free to contribute something even that's coming up. A good place to start with that is to reach out into that issue. If you see something that's already kind of scheduled or being discussed, you could ping in there and talk about and ask about, you know, what our plans are what and how you might be able to contribute. UI polish items, if you're a front end developer, are a great place to start. Most of these are all going to be accepting merge requests as well. But UI polish typically means that there's just something a little bit weird in the UI, and it can be corrected hopefully pretty easy. Sometimes there's a little bit of a back end work to change the data that we're sending to the front end in order to make these work. But usually these are pretty self contained and don't really change a ton of the core functionality of the application. And then community contribution are ones that these have been flagged as already in progress. So there's already community contributors working on these and actively working on delivering them at some point. So these are good if you want to collaborate with somebody, if you're not feeling confident about delivering something on your own for the first time, you can jump in here and potentially offer to help and learn a little bit from the folks who are working on this. The other sections here are just what's what's coming next in our next few releases, as well as other interesting items that we've tied this being potentially cool things that we plan on doing, but don't have committed to a specific milestone yet. So hopefully all that's pretty clear. I think that there's a couple of different categories that are good to potentially start working on and and do cool things. The first one is a good one. Review apps is a good one. Pages is a good one. And I would say, I would say that probably those are the first three good ones that you could really look at and work on something that's independent and deliverable and can add value without touching a lot of the core functionality of the application. That doesn't to say that there aren't really cool things to contribute in each of these other categories. So if you find something there, please don't be, you know, dismayed that or discouraged that you shouldn't contribute something in those categories, you should. But these are going to be good ones that are more, you know, evolving and and are you're going to be it's going to be easier to find ways to contribute. So most of these categories and all the categories and all the different stages also have a web page that talks about what we're doing for that specific category. There isn't a contributing section here to supplement the one in the other section, but you can find issues here by looking for example at the issue list. So what I did was clicked on the issue list here, and it brought me to all of the issues that are open and with the feature flag label. So here they're some with accepted merge request some of you I polish and so you can sort of use that the same filters and you can even add them here. So if you want to see only the UI polish items, you can select that here and find everything that's related to feature flags. That's just the UI polish item that again if you're a fun and developer might be a great place to start. But overall, there's all kinds of interesting things in here. Feature flags is really great because it's a very new feature. So we're adding a lot of basic functionality to a very simple bit of code or relatively simple bit of code. It's based on the Unleash client library so we're building a back end that's compatible with the Unleash client library. And so if you're already familiar with that that could be a great place to contribute. There's a lot of things here about logging. There's about adding new kinds of access controls and different kinds of that and by access controls I mean different kinds of filters about who's going to be able to see the feature. So right now you can turn it on or off per environment. We're adding that you can turn it on or off per user ID, you can, you know, there's percent roll out there's all these different kinds of things that we're going to be adding, you could contribute those. So that's the, that's a good summary of the future flags I think these maturity plan items are specific ones that we've identified as being important to bring the category to the next level. So if you really want to contribute on something important to the to the category, then this is a great, great set to look at some of these maybe more complicated. That's okay. Again, if you want to work on something complicated. That's awesome. We welcome that. But I would encourage you to reach out in the issue and just say, hey, I'm a contributor. I want to add something to this. Do you have any feedback and then our technical folks or me as a product person will jump in and help you out. We've also got review ups which I described a bit. There's a lot of improvements here. There's a lot of quality of life improvements here as well, where again, you I polish items to be found all over the place. And if you have something like you're interested in iOS Android development, if you're interested in other ways of using review apps. There's a lot of cool interesting things here to work on. Let's say gilab pages is another one that's very, very similar gilab pages is pretty mature and out there. So it can be a little bit more daunting to learn how it all works. But if you're passionate, a passionate pages user, and you want to improve the user experience, there's definitely stuff in here. And I will touch on one more area that I think is interesting within the release orchestration category. I'm going to introduce the concept of releases. So you can put you can create a release associated with a tag inside of get repo, and then publish release notes to it and it has other elements where you can attach a binary to it. It's like the startup gz of whatever you built, and it has other metadata that you typically associate with a release that feature within the release orchestration category has a ton of interesting things to work on. And again, it's a very, very new feature so it's not complicated too complicated to get started. And there's a lot of you I polish items in here like, you know, simple things like allowing to delete an environment for you are. We've also got interesting things that we're doing very very soon like right now you can create a release, but it just exists and it takes the date of the date that you created it and it's all very simple. What we want to allow people to do is set a date for that release, and that date can be in the future. And if that date is in the future that it's a draft release essentially, and it's not if it's a date today or in the past that it's an active release. That's actually fairly straightforward to implement if you're looking to contribute something. And that's actually very, very important. It's listed on our, our list of, you know, items for maturing, sorry, not this one either. It's listed on our list of items for maturing the category here so there are small things that are very, very important here, and across all of these things. I'd also welcome, you know, you can reach out to me through Ray or you can find me on Twitter, my handle is J4LENN, J4LENN. And it's easy to get in touch. We can talk about what your skills are, what you're interested in working on, we can find something interesting. I think that I've covered most everything. Ray, did I not touch on anything that you think- No, no, I think you did a wonderful job. I mean, the only other thing that I wanted to point out, if people are interested, like below the contributing section, if you scroll down, I think you have like plans for upcoming releases, if people are interested. Yeah, and then like even like Q3 and Q4, I mean, you have things sort of outline like link to issues. And I think a lot of these are accepting merge requests as well. Yeah, almost all of them should be. And even things that are coming up, like we're starting the development on this in a few days, but you're welcome to contribute with us. You're welcome to collaborate. It would be great. 12.3 we haven't even started yet. So all of these things are very welcome to be contributed. Yeah, so I mean, so like sort of like our roadmap is sort of out in the public. So we welcome, obviously, people's feedback. And if you have any questions, I mean, feel free to ping either me or any of the product managers like Jason, I'll be happy to answer your questions. And I mean, thanks, Jason, for bringing up contribute for prize. So right now the prize is a Moleskine notebook. I mean, that's sort of that's laid out in the handbook. I mean, if you work on any of these issues during the hackathon, you can basically double dip on prizes. I mean, get the prize for contribute for prize and I mean, get the prize for the hackathon as well. So another like a small incentive, I guess, just checking the chat to make sure that we don't have any other questions from the audience. David, was there anything that you want to cover as well or I was sure I had a list of questions and Jason consistently was answering every one of them in the presentation. I don't have one though. For new contributors is not always obvious. If they start contributing, they might not even follow an issue, they might file an issue themselves and start working on it. So in that, in that, in that regard for them is not as obvious as which stage they're working on or how they should tack that, that, that money request. Which guidelines would you have if it for, for some contributors, if they're developing a new, a new feature or fixing something in numerous requests for them to use that tag DevOps release and who to pin. I think, Ray, this might be better for you to answer. I have some thoughts on it. Of course, like, I think it's good, very good to connect early with the team that's actually going to be doing the work, but it can be quite complicated to, to find that right team and to be working in our, you know, overall strategy to figure it out is complicated. Ray, does your team help with that. Yeah, I mean so we, I mean, I think in the previous session, David mentioned this we have a bot that scans through all the community and then, I mean, I subscribed to that label so I mean, I do my best to try to triage him. And, you know, Jason, you've been pinged by, by me several times, like in the last week or so I try to ping the pms and, and the engineering managers, whether it's back in to, I mean, at least let the community members know that who the right people are to, to start to review and start to conversation. So, yeah, I mean, I definitely try to triage him. And if Jason tells me this belongs in a different category then then we move on to different product managers and different people. And that's totally fine. It is complicated to navigate, but do endeavor to, to reach out to someone even if it's reaching out to me directly on Twitter or to Ray or whatever. I'm not sure where this goes. More than happy to help. We love contributions. And we, yeah, we would just love for you to contribute. We don't want you to get frustrated and kind of get lost in the administration or bureaucracy and how this all works. Awesome. Thanks. I guess. There's no other questions will just end the session here is thank you Jason for free time and for this will all also be added to the playlist for for the hackathon so I'm sure there'll be a lot of people viewing the recording as well. Thanks Jason and enjoy the holidays tomorrow. Thanks Ray and thanks to all the contributors. Thanks. Thanks guys.