 Welcome everyone. Thanks for joining today's webinar. We are very excited to have you on. My name is Timothy Tran and I'm a field marketer here in APAC at GitLab. So in today's webinar, we've got Jonathan joining us from Singapore who will tell us more about why GitLab CI CD with five hacks to improve your current CI CD setup. As well as special guest Rob Williams from my previous webinar joining us to answer all your questions during the live Q&A at the end. It's just a little housekeeping before we get started. This webinar is being recorded. So the presentation and slides will be emailed to you after the webinar is finished. If you've got any questions during the presentation, please just type them in the chat box in your Zoom control panel below. I'll compile them during the presentation and we'll give some time for Rob and Jonathan to answer all your questions at the end. We'll also have a couple of polling questions to kick off the session. It will just pop up on your screen and all you need to do is pick an answer that is most applicable to you. So let's get to show started, shall we? I'd like to introduce to you or Jonathan Lim. He's a senior technical account manager at GitLab. Prior to joining GitLab, Jonathan worked in the big data analytics and application monitoring space. Having seen the cost to rectify production issues, Jonathan wants to help organizations like yourselves adopt DevOps best practices to fix problems earlier and quicker. We've also got Rob, our panellist for the Q&A, who's an experienced DevOps engineering consultant, who in the past has worked with large enterprise organizations to build and deploy web applications, as well as roll out digital workflow transformations before joining us here at GitLab, where he's been helping organizations bring modern DevOps best practices to more companies. Jonathan, please take it away. Hi, everyone. I'm just monitoring the chat. It looks like some people are having issues with voice or something. Can you hear me alright, Tim? It's okay. Yeah, I can hear you. Anyone else having problems? Okay, I think there's just one person. Okay, thanks for the feedback. Okay, cool. Yeah, so I'll just move forward. Sorry about that. I was monitoring the chat because I think some people were having issues there. So first and foremost, thanks everyone for coming. So my name is Jonathan and I initially, Tim has actually introduced me. So just to get an idea about like the, you know, get a few around the room, like how everyone is comfortable with the topic on like CI CD and DevOps, I have a few polling questions. It'll be great to get your feedback on that so I can, you know, tailor my presentation in a way that helps that, you know, in, if there are certain words that are more technical, so I might give a bit more of an explanation. So let's just get on with it. So with the first question is how familiar are you with continuous software development? So, yeah, this again is anonymous. It'd be, we just want to get an idea on like what people are having. Right. So we have about 70, 80% of the people responded. Also, let's just give it a few more seconds. Right. So, so these are the poll results. I'm not sure if you can see the poll results. But we basically have some level of familiarity. I think it's a little bit somewhat familiar, familiar and not familiar. So I guess a lot of people in this call are quite familiar or at least know what DevOps is about. Just two more questions about that. So the second question would be, are you currently using GitLab CI CD? Okay. 80% of people answering, we are pretty much neck to neck at yes and no. So that's good to hear actually. So it'd be great. So for maybe the folks that are using GitLab CI CD, you can help us as well to answer some of the questions if they appear on the chat as well. So we're getting, for the poll results, we're getting pretty much neck to neck on about 50% yes, 50% no on sort. And last but not least, the last question would be, how far are you along your DevOps journey from one just started to five very mature. All your teams are using it. And, you know, basically you're here to fact check whether I'm talking about the right things. Okay, so yeah, some most people as I can see are within the earlier stages from one to three, which is great, I guess. And so I hope this session can be a little bit more informational about how we see it here at GitLab. And let's just move straight into the presentation. Right. So in 2011, Mark Anderson, who was a former founder of Netscape mentioned this cycle time compression may be the most underestimated force in determining winners and losers in tech. So what does this actually mean is that the quicker that you get feedback from your users from your tests, the faster than you know your off track. And therefore that results in less time, less money and less effort that is wasted for you to get back on track. Right. So in the past as we know as software development lifecycle we had the waterfall methodology of how we develop products. There is of course the design stage where you get the designs from the end user from the customer. And then you go on and then six months later you say hey customer six months later I'll come back to you with a prototype also and we'll discuss it. Six months on when you reach the when you have some prototype ready. What happens is the customer might have moved into a different space their business might have evolved their requirements might have evolved. And they come back and tell you hey you know this is not what we want. These are the new requirements that we need. But what I have in that scenario, you have basically wasted a lot of time because you are already moving in the wrong direction. That gave rise to the idea of like agile methodologies in which you get to see your feedback faster. You don't have such long iterations where you where iterations can be three months or six months long. But what you see is that you in agile methodology you have a smaller number of features that you would develop on you then push them into production and you ask the customer for feedback quicker. DevOps came around around the same time as after agile methodologies came about in which you then have you give power to the developers to allow them to be empowered to know how the feedback is like to not wait for to have it siloed teams where developers only develop and in your operations teams only just monitor the end product. So organizations then move to the next stage right so organizations will try to adopt DevOps try to bunch of buy a bunch of tools to help the organization and they said hey you know I just bought a bunch of tools developers here you go. Please use it automated automation is always a very big word and then they want the developers to actually adopt DevOps as a tool. As we know, as the polls, a lot of people do know about DevOps DevOps isn't just about to this sounds a bit hypocritical coming from product companies such as GitLab. I still strongly believe that it tools are just in aid in in helping you to adopt a DevOps methodology at your workplace, but it really boils down to really the people processes and the tools as really the last thing. We can really help you with the people and processes, we can have a chat later on and then as a technical manager that's my job as to guide customers along that journey as well. But today we're just going to be talking about tools and how we can simplify these tools for you. Just as a side note, there's a very interesting book called the Phoenix project that you can consider reading about DevOps it's not very heavy it talks a little bit about DevOps in general and gives you high level of views and it's a little more engaging if you want to learn a bit about DevOps. But that's not why I'm here to talk about today. I myself consider I consider myself as a millennial I mean I am millennial, and I only had my first phone when I was like 14 or 15 back then it was a Nokia phone. It didn't have any cool features I only could play snake on it. And at that point in time, we had dedicated features and functions for each different tool. So we had really good cameras from Nikon and Canon. We had like MP3 players, we had Walkman, which played your CDs and so on and so forth. We had dedicated computers, pages that did what they did really well. So they were very good in their own right. But what we ended up with was that we had so many devices that came rise with the next component. So I think the first one that I think a lot of people might think about is the first iPhone. The first iPhone was really where you actually see all of these different tools come together in a single device. So you had on an iPhone, you could have your phone, your calendar, your cameras, you could see whether you could hear music, you could browse your web and then you basically replace your alarm clocks a lot of the time. In the first iteration of the iPhone, of course, the camera wasn't the greatest, but as you know now we are, I don't even know where we are at now with the iPhone X or 2X or something. The features and functions have really improved over time. So I think that's kind of where we see ourselves at GitLab to be in the same direction as we want to have an all-inclusive platform, right? It's a complete DevOps platform that runs end-to-end, right? All the way from Manage to Plan, Create, Verify, Package, Secure, Release, Configure, Monitor and Defend, all in a single platform or in a single pane of glass where you can actually see everything, all using the same permission model so you don't have to integrate all your LDAPs with your many different tools and so forth, all in a single data store. And that kind of simplifies it. And more often than not, we also preach about a lot about it within the company about collaboration between the tools. So if everyone is using the same tool, it doesn't leave a lot for, you know, how do you say, conflicts between teams which is like, hey, you know, my tool says this, but your tool says a different thing. So having one single tool is what we then would prefer. Or what we, that's our vision for the DevOps lifecycle. Unfortunately, today, as we are only going to be doing this for about half an hour or so, we will only focus on these three stages. Again, with me, we have Rob who actually talked about a little bit about a different topic. We have Summer, which was the previous speaker as well, which talked about DevSecOps, another topic in general. But what today we are going to talk about is these three stages which is Verify, Package and Secure, or what most of us known as CI CD. So we will, this is an ongoing webinar kind of session, and then we'll be talking about like other stages as well. So stay tuned if those are the things that you're more interested in. So let's define what CI CD is. So CI CD in a very, very short definition also. So it embodies a culture set of operating principles and collection of practice that enable application teams to deliver code changes frequently and reliably. I think one thing to note here is that you don't see the word tools, right? So again, I want to emphasize this, even coming from a company that sells a tool, is that tools are just a way to help you to enable that culture, that operating principles. And hopefully through today, I will share with you some tips or some tips that our larger customers at GitLab are using today that help them to actually adopt these principles a bit better. By the way, yeah, I think by the way, I think Rob and Tim and the rest of them are monitoring the chat. So feel free to ask any questions if you, you don't have to ask the questions at the end of the presentation. You can ask it throughout, but we will address them at the end of the presentation as well. So why CI CD? So why do people use CI CD? Because obviously it detects errors faster. It reduces integration problems. It allows teams to develop faster. And first and foremost, it helps you to deliver value as quickly as possible. GitLab has its own way of CI CD or the way that we actually have a methodology around its CI CD. And this is to understand it first is to understand the GitLab flow. So right in the middle here, you do see the master branch. So the master branch is where how a lot of people see as the source of truth. When you were to actually make a code change, you were to actually develop something new in terms of your a new feature for your application. You can create an issue first and then that would as well as a merge request, you commit your changes, your CI pipeline runs, you then have your security scans and all your other tests that you have in your pipeline. You review the applications, you approve the changes based on your team lead or how your approval changes are, and then you merge it back into master. So how we see this works is that this is the GitLab flow and this is the cornerstone to how GitLab continually integrates and deploy. Why is this important? Because you know, a lot of the times when developers they develop on their own laptop on my MacBook machine also, you know, it works fine. The code works completely fine on my MacBook machine because it's a lab environment, right? So there are no external factors. There are no, you know, networking factors. There's no like other factors that involve like even for your web applications or how you integrate with other tools. So having the following this GitLab flow to test it even before you merge it into master is very important in our case. Site tracking a little bit. That's the whole idea of DesakOps. DesakOps as summer, our senior architect that's based out in Melbourne talked about in our previous webinar. That's also really important. So as you can see here, we have the GitLab CI so you actually integrate continuously. The other portion of it is the security testing in the pipeline. So following back on my previous slide, which is about the GitLab flow. So you test for your security vulnerabilities, you test for your license compliance, you test for your code management so and so forth. And then you give the feedback directly to the developer even before it gets released to the security team, right? So this empowers or has the idea of shifting left to empower the developers to actually get feedback on whether the new features and functions that they are actually developing is in compliance, has no security issues, so and so forth. Right. So again, I can't really go too deep into this topic. But if you would like to have a chat about it, let us know and then we can have a separate conversation about it. Expanding a little bit about the GitLab CI CD workflow. So within the continuous integration component, you can have it, as I mentioned earlier, your code quality test, your performance test, you can integrate with your third party test as well. If you have like JUnit testing, you have unit testings available in your own flavors, you can definitely put it as part of your CI pipeline. And then you can use the features that are available from GitLab, which is like container scanning, dependency scanning, fast testing, which is something that we've added recently as well to our security stack. And moving on to the next component of it. So like your package registry or how you manage your packages for Maven and MPM, and even to your release stages where you integrate with a technology such as Kubernetes for your canary deployments and all. Right. So today is going to be a very high level review. I have, I am not able to go through every single feature of them. But if that's something that's interesting to you and you want to have a discussion, we can always have that later on. So, in general, how we see our CI-CD pipelines is this. Firstly, there are the main stages you have the stage for build, test, review and deploy. These are just some example stages that you can have as part of your CI-CD pipeline. It doesn't mean that it's limited to only these four. You can have custom stages as well if you want. You can have, you can have, you can split up these stages as you need to. And you have can have many multiple number of jobs in these stages that can run in parallel or, you know, only after or sequentially after one stage of after one job has finished. Right. So that kind of gives gives an overall or like a high level overview in terms of setting the ground in what GitLab believes in CI-CD and how we actually see the DevOps landscape to be in our own words. The next thing that we want to talk about, which is basically the meat of the presentation is the five hacks. Right. So what led me to even come up with this topic in the first part is actually observing customers and talking to a lot of the people such as Rob and Summer and a lot of my colleagues as well. What are the customers, what are customers asking for today? Or what are customers facing problems and challenges in their organizations today that has led us to this topic, which is five hacks. So first, let's go on to it. So first things first is the problem where customers always come back to us is that first things is as the poll suggests. So some of you guys, some of your teams are having issues with or you find it very imposing, very difficult to switch to DevOps. One of the reasons why it's that a lot of them, you don't have the proper resources, you don't have the proper people with the correct two sets to be able to adopt these DevOps practices or to adopt CI-CD. It involves a very steep learning curve and I agree to a large extent, but how do we solve this problem? So I'm just going to go through all the problems first and the next few slides will actually talk about the issues. The next one is how do we ensure consistency of our application builds over multiple cloud environments? As a lot of companies are moving to the cloud native environments also, ensuring consistency over across Azure, AWS, across GCP is getting more and more difficult and how do we help that? Number three, how do we handle secrets and environmental variables as per company guidelines or even by audit guidelines per se? Number four, how do we effectively run test monitor applications that involves microservices and multiple technologies, especially when we work in silos in a development unit? Right, so these are some of the problems that we see our customers come back to us and ask us how can GitLab help in this scenario? And these are some of the solutions that we think or some customers that adopt these solutions and we think that might really help in this case. Right, so first solution, simplify your CI-CD, the steep learning curve, you don't have the proper two sets and all that. Developers find it very stressful to actually learn deployment code such as your Jenkins file or even writing in GitLab CI. So before I start, maybe just to have a bit of, does anyone know what this tool is that I'm showing on the screen here? Mixer, I see mixer, any other guesses also? Ah, okay. All right, I see a lot of people know what they're talking about. Okay, filter. Yeah. Yeah, okay, so I think that yeah, there are many people who actually know what this does. So yeah, this is actually a thermomix and if you like squint, oh, we even have the actual model which is TM5, right. So if you squint hard enough, you can actually see the brand on it. This is not a product placement nor are we sponsored in any way. But what this tool actually does is that it's a food processor and cooker per se. So it's all in one blender, cooker, bread maker, and it basically is able to cook anything. It has basically over 600 recipes that you can actually cook. And all you need to do is just put in the ingredients and you actually cook the dish for you. Right, so that's pretty amazing, right. And I think said it to forget it. Okay, right. I see there are some fan boys or fan girls out there that really like this tool. So in the same vein of track, I think where we are coming from is that we also believe that, you know, we don't want these things to we want to automate some of these things we want to make it easy. So what how would night how how nice would it be if you were to be able to actually, you know, you can sense what the ingredients are so and then automatically help you to deliver the end product as we go. I guess that's where we come in with the idea of auto DevOps. So with auto DevOps is the idea that all you need to do is commit code, push code and get that will automate the rest for you. Right, so what get that does is that if you push a code in a proper format and of course there are some configurations that to be done. I'm just going to give you the sales pitch is like oh just put it and everything's fine but there are some very basic configurations they need to do. And it will automatically help you to create these stages. So from create merging a building to verifying code quality testing security in different ways or so for packaging for releasing configuring and monitoring. Some of these things are set up properly. And that's what we think is the best way to bring these best practices to develop to delivering software. This is an example when I basically use a template of a spring boot application that's written Java. So I didn't write any CFL I didn't do anything I just start with a template and automatically it would help me to and I run a pipeline. It would help me to actually set up these stages for me. Depending on what kind of different technologies you are using we would then have different pipelines as well that will help us help you to set it up accordingly. Right, so that's my first thing auto DevOps, auto DevOps again, it can be used in conjunction with your, with, with your customized CI pipelines as well. It's a case where you just have to use auto DevOps and you know it's a fire and forget. You can use it in conjunction and but it what I'm trying to drive it is that it's a good start point right so for teams who do not know what to do at a start and are trying to adopt DevOps practices. That's a good start point for you to start and to get that feedback quick enough. So that's one down there's a for others more to go. So point to effective deployment of cloud native applications. So how do we ensure standardizations of deployment across multiple cloud providers and deploying on native applications on cloud native. So this is typically how a lot of developers or like a lot of our customers that make use of GitLab. And in this problem is that maybe they do have a good lap instance they have, and they, they have many projects right and there are many projects and they span across multiple product as a cloud vendors so they might be deploying to Amazon AWS or Google GCP as well as Microsoft Azure. And they have different technologies they might be trying to use GitLab to as GitOps to actually deploy infrastructure as code or even application as code but it's very very difficult to actually ensure that this standardization happens. So why is that difficult? Say for example, if your application now support Nginx 9.0 also but Nginx comes up with a new version of it. How do we ensure that that is standardized across all your three different cloud vendors? How do we ensure that all our application adheres to all these security best practices within the organization as well. So we at GitLab I think we leverage on a few different methodologies or tools as part of our DevOps process and first things first is the idea of build packs. So the answer to that is build packs. So we started out with a Heroku open source based project that's called Heroku-ish and now we are moving actually to a new standard for cloud native build packs. So in a nutshell what Heroku-ish or Heroku and cloud native build packs do is that when you deploy code, what it does is it analyzes the code, it selects the build packs or if you have certain assigned build packs to your code, retrieves the assets, help you to compile the code and then create an app slug for you to actually deploy into environments. In conjunction leveraging with a Helm charts and auto DevOps, it can then help you to deploy straight into production or your UAT or testing environments in this case. So that's part one of how we can actually enable that standardization. Why is this important? Because build packs firstly they help you to maintain a control between the apps and the developers to ensure that standardization also allows for compliance. There's very little effort and intervention when you're using build packs and as well as why are we, I think one of the questions that we got is that why are we moving away from Heroku-ish to actually cloud native build packs. So first things first, Heroku-ish is an open source project that's maintained by the community. We are not sure when support will stop or when people are actually not going to contribute to this project anymore. At the same time, it wasn't Heroku-ish, it wasn't born out of a cloud native background. So the Docker images are a little bit larger and in our team we're actually monitored and the build times are a little bit longer. So moving on towards something that the cloud native computing foundation is working on is something that is more cloud native, it's a bit lightweight and the build times would then improve accordingly. And that would also help you to speed up your efficiency and automation process with AutodevOps. Okay, so that's part 1A of it, so part 2A of it, part 2B of it is actually our Kubernetes integration. So we believe very strongly and we invest heavily in integrating with Kubernetes to actually have some of these dashboards to get that feedback early on. So having the deploy boards, canary deployments, including AutodevOps, Kubernetes monitoring and integrations with web terminals, that's where we are at with Kubernetes integrations. And what you get to see out of it is how fast or how having a little bit more control and a little bit more view into your deployment models. So part of your CD component where you can actually see how many instances or how many ports are up and running in your Kubernetes deployment. You can actually also see in terms of your canary deployments on production, are they working fine, are they up and running? You can also monitor it directly in for your node metrics, such as your average memory utilizations and CPU utilizations. And all of these ones are all available in the GitLab platform, so you don't have to switch to a separate tool set, like using maybe a Kibana or Grafana dashboard to actually view all of these statistics and metrics, you can see them all directly in the GitLab platform. So again, going back to the idea of having a single DevOps platform where you can see end to end in terms of like your feedback and all that. Right, so that's point number two. Okay, so first one we talked about AutodevOps to actually go to actually climb to go past that mountain of like adoption. The second one we talked about how to maintain that standardization. And number three, handling multiple pipeline projects. So over here in the screen, if you can see here, this is the basic GitLab application architecture. You have multiple components such as, you know, your engine, your work costs, your unicorn that's running on Ruby on Rails. You have Redis, so and so forth. This is an architecture that might be very familiar to you, even in your organizations where you have multiple services or microservices that are talking to each other. And teams in general wouldn't be working on every single part of this architecture. So you have a team that maybe will be working on Unicorn and another team that's working on your work costs. Right. But how do we test this effectively? So at GitLab we do a lot of, we make use of our own products and we are able to actually test this in parallel, right? So able to test on our own application and how it interacts with different applications. Right, so that might be the same at your organization or that's what a lot of our customers are talking about where application teams might want to see how my new code that I've been pushing in, how it interacts with a different component, a different component when something new gets pushed up. That gives rise to the whole idea of multi-project pipeline. So you specify a branch, you can pass variables from to downstream pipelines and if downstream pipeline fails, it will not fail the upstream pipelines. How do we do it? So in your CI pipelines, you can actually specify a new stage called bridging and in that new stage called bridging bridge, sorry, you can then specify the project branches and your strategy on how you actually want this to run. What it will look like in your CI CD pipeline would be this. Firstly, you have your initial branch that may be written in, as I mentioned, it could be running on Ruby on Rails. So it goes through the entire build process. It actually deploys all the way to your downstream and then once everything passes, it would then actually trigger the downstream project, which is another project in GitLab to actually run their own tests and their own CI pipeline. So that's how we deal with multiple projects and a lot of these days like advanced projects that have multiple services that are talking to each other. So that's point number three, right? So we've also covered the issue on like how do we test effectively for multiple projects? And fourth, right? So how do we optimize resources using GitLab rules? So prior to rules that GitLab prior to actually 12.3, there were only conditionals that we could allow. So we had conditionals that allow you to specify only or accept into your conditionals. And after 12.3, we actually changed the rules a little bit better. So it's a lot of improvement after 12.3. So we provide the users a bit more control when on how CI pipeline should run. So we understand that compute resources are very expensive. And if you maximize your resources, you can save a lot of money, right? So you don't maybe certain stages you don't want it to run for. You can specify tags for certain CI pipelines where, for example, if it will be part of this conditional, it doesn't run and it therefore saves a lot of computation power. So I had a previous colleague at my previous company that was telling me that a certain large amenity in Korea was spending approximately about $800 million on AWS spending in Korea. So I think that's one of the biggest problems that a lot of large organizations these days face, which is trying to reduce their compute spend and how to actually have more control on these things. It's very important. Right. So even in GitLab, prior to 12.3, we had a lot of these kind of errors. So you would commit a certain code and that certain code might, because of the tags that you placed in and because it was a merge request as well, it could potentially run two parallel CI jobs at the same time, running exactly the same thing. That number one is a waste of resources. You don't want to spawn CI jobs, both at the same time because they're basically running the same things. And at the same time, you don't want to make your runners busy in this case. So how do we actually put rules into our CI pipelines? Right. So this is another hack that we use or that we suggest moving on from just using only or accept is to use rules in your blocks. So specifying a rules in your block and specifying your conditional. So for example, in this case, if your CI pipeline source equals to web, then it would then run the script as it says. There are a lot of clauses. So just now we mentioned in our previous example, there is the if clause that you can use. There are also other clauses such as changes or exist. And there are other operators that you can use to actually specify your GitLab CI to have that additional control also. So some of the ones that that are very popular is safe. For example, if you if the environment is you're deploying on is to production, then there are only certain type of jobs that would kick in. If you are not if you're only deploying to a test environment, then you can only spend you you'll be only running a certain set of jobs. Again, this is one of the examples. So in this example, you can see that in this job, for example, if the CI pipeline source is a much request event, or if it's a schedule project. So you can then have the control to actually run the script. Hello, hello world or echo hello rules right in this case. So there are a lot more examples, but we I don't have the time to actually go through all the different examples or so. So just do a quick Google and you probably can see what some of these examples are in terms of your CI pipelines. Okay, so the last last but not least I think it's environmental variables and secret management. And I think this is really important today. Over here on my screen, you can see. I hope no one here is working. This is not a call out to the company. So if you're working for like Facebook T mobile or like Robin Hood, this isn't, this isn't like trash talking but I think the idea behind it is what we want to talk about is that a lot of people we we still today face the problem of having to store a lot of passwords in clear text, and we don't do them in a proper manner, not only just passwords but also environmental variables that might be crucial in terms of connecting to your environments in the cloud or even your on-prem or certain other features and functions. So get that so doing so that this is a very important component and I think this component also ties in greatly into how we actually manage these secrets as well as these environmental variables well enough. So I'll talk about two areas that you can actually control these variables. So first one is under your CI CD settings as part of your variables you can actually specify your variables here. And if you can see the the values here actually you can't actually see them you can review these values and the and you can you can control like who can see these variables via RBAC sources so a role-based access sources so maybe only the admins can see it. But if you were a guest user or you're a developer you can see these variables and then you can also control it in a way where certain variables are only activated for certain branches right. So you can have the idea of protected branches versus unprotected branches where these variables will only be accessible or you can actually call these variables if you're only on a protected branch. So that's one way of actually managing these secrets or these environmental variables. So say for example if you are not if some of these variables are not so confidential or not so secure you don't need it to be secure you can definitely put it directly into your Qtlab CI file as well as a variable and you can then reference it from that point onwards. But what we see here is that there is another component which is highly requested by a lot of our customers as well as a lot of our customers and a lot of people are starting to use this in our latest version as well is integrations with external secrets in CI. So as of our last our last release or so we've actually had achieve vault integrations with Hashi call. So as you can see from the diagram here this is basically how you can use an external secrets application to actually do that whole authentication process and not store it within GitLab if that's how your organization sees it to be. I've also had some conversations with other customers and their interest in other secrets management tools such as maybe cyber vault as well and so on and so forth. Right, so I think we've only started on this journey relatively new. So I think as an open source company also I would suggest if you want to see a certain feature from us please create an issue on our through GitLab and then you know suggest why this is important and then I think our developers or our product managers will then you know they'll pick all of these up and then they will start to focus their development efforts on actually supporting these technologies. As far as our secrets management. Right, so I guess that's pretty much it from my point so that's point number five. And these are just five hacks of five tips that that some organizations that are using GitLab are using that they are doing it today. And I suggest that you give it a try or if you are using if you're already a GitLab CI user CI CD user or if you're not you know there's always the free trial that you can take that on and you can always try in your organization. Yeah, so I guess that's it from me and I think we can move on to the next part, which I will let Rob take over. Awesome. Thanks for that Jonathan very insightful presentation. You know it's great to hear all those tips and tricks and I hope everyone has a lot to take away from this. So if you guys got some time, you know stick around for the Q&A. First off, we'll start off with a question from Lewis is auto DevOps available on the self hosted version. Definitely so so I actually saw this one get answered in the chat as well. So some people are already on top of it right auto DevOps is totally available in the self hosted version. It's the auto DevOps can basically be thought of as a set of templates that are that all work together to create one pipeline. But then, in addition to that pipeline being be working both in the SAS version and on prem you can then compromise the jobs and create custom pipelines from it. Great. And what's the difference between good lab and spinnaker like from a CI CD perspective. Yeah, well like from the CI CD perspective. There's there's some things like like the auto DevOps pipelines right like things like integrating tightly with the Kubernetes and some of our operations dashboard. A lot of the biggest benefits that you're going to see with good lab versus a tool like spinnaker is sort of around the edges of the CI CD space right because we integrate with the fully with the create tools fully with the monitoring tools and that sort of thing. And that lets us do things like the feature flags and the secret management that Jonathan was talking about earlier. Definitely. So is it possible to have multiple pipelines in the same respiratory. In the case we have multiple apps in the same repo. That's a really interesting question and it's a use case that they can happen a lot and especially in the old like sort of mono repo structure that that a lot of report repositories still are in. And the best answer that question is that while there can't be to explicitly defined pipelines per se, what you can do is dynamically change how the jobs run so that they only run when certain conditions are met. And what that has ends up being is a very dynamically generated pipeline that can run different jobs based on different factors so that when you push up a job it might have an environment variable set. And then that can trigger the jobs that you need to run to run and the ones that you don't want to run can be turned off. Perfect. So what do you recommend for handing secrets in GitLab pipelines and on developers local machines having secrets stored in pipeline settings doesn't allow for easy updating or changing. I mean that doesn't help for secret management on developer desktops. Does GitLab have a solution or should we look into tools like how to call fault. Like, even if you if you go and get actually called vault right if the developers are still putting the passwords on their desktops then then actually calls not going to be able to help you too much. What what we talked about right the secret management in the project variables what Jonathan was talking about earlier is the recommended way of working within within GitLab. But the hash you call bolt integration as well as is very deep and like it actually works very well and very seamlessly to get your secrets in and out of vault into your environments and pipelines. Cool, that makes a lot of sense. So how do you put put an approval method in pipeline for a particular job. Interesting so so. The job will have certain success or failure criteria is right so job is considered to be successful when it reaches the end of its of the pipeline script. So, for each pipeline job, there's a set of instructions that that the GitLab runner machine will run. And then if it successfully reaches the end of that, then it's a successful job. If there's some sort of error that gets raised by your script before that happens or there's some sort of something gets raised and some sort of exit code gets given then that's a failure condition for that job. Right. This one's a good one. We get this quite a lot is GitLab CI faster than GitHub action. How do you compare. Well really it really depends on like what you're doing right so in terms of like the only thing that I can sort of point to to compare us is the analyst reports right and and GitLab CI is the number one continuous integration tool on the market at the moment so that's going up against the likes of Jenkins, the likes of GitHub actions. So, that's a, yeah, let the credential speak for themselves I suppose. Yeah, definitely, definitely. So how do you, how do you block the GitLab CI YML to be edited while merging from another branch. Well, when the way that you do that is by enabling merge approvals on the merge requests, right, it's impossible to stop any individual file from being changed in the Git repository. So the whole point of the repositories that you get, you get like the version control you see all the different versions. In order to stop the pipeline from sort of changing and this sort of thing and especially in terms of like long living branches they get merged in after a while when that there could have been like lots and lots of changes based on other other branches. There's this concept of merge trains within GitLab CI, which allows you to set specific merge requests as prerequisite for other merge requests. So that means that if there is a change, then it has to go through that merge train first and make sure that all of the, all of the mergers have been put in. I see I see in the chat could also try file locking. Yeah. Great. Does GitLab have a solution to order deploy Jira custom plugins automatically to running Jira instance. At the moment I think that still has to be configured. You have to configure the integration there. But once you do have it integrated, there is a full range of features including closing Jira tickets from the GitLab interface when you push Commencer. I got another comment and question from Lewis. In my case, I have 10 done that API is in the same repo and dev stage production branch. Should I use conditions on the pipeline file to trigger the build for a specific folder from a specific branch origin? Yeah, definitely. So that's that's one of the most common. Usages of the GitLab rules is having specific branches run specific jobs. So we can see this in the auto demos pipeline. One of the one of the cool things that does is it has a separate pipeline for master versus for every other branch. And on the master branch, in addition to all of the regular jobs, you build your code quality, all of our security scanning, including the the auto review app for the dynamic application security testing. It'll then deploy to a staging environment and then have the option to have either incremental rollout timed incremental rollouts to print to a production environment. Manual deployment to a production environment, or even canary production to a deployment to a production environment. And then after that deployment, it even has a performance testing built in. So those are some of the things that are just specific on the master branch there. So you can definitely like pick up individual jobs for specific branches, especially in the dev stage branch branching model. So parent child pipeline seemed to track the entire results compared to multiple projects with triggers. Do you have any roadmaps providing consistent view on them? So as you said, there's no like upper level view, you can you simply have to like navigate up and down to the parent child pipelines, because they are separate projects and they have a separate context. So I think that at the moment, there's like they're just trying to maintain that sort of context there. So I'm not sure about a timeline for providing a more global view on them. Jonathan, you heard anything? Yeah, I think I agree on that point. I think they want to see that separation. By the same time, you know, if it's something that you think is useful, you know, some other issue on our project and our product needs will probably take a look at them. I mean, it's a good point to add as well. So, yeah. Does GitLab support open road by Acton? I'm sorry, I haven't heard of that. Depending on what it does, potentially. Yeah, I haven't heard of this one as well. Okay, we'll come back to it later. So does GitLab support versioning? So in terms of versioning, so for GitLab is a version control piece of software, one of the functions of GitLab is a version control software, right? That sits in the Create DevOps stage, so we've broken it down to the 10 DevOps lifecycle stages. And Jonathan here has really been focusing on the Verify package and release stages, which lets you enact pipelines on individual commits and branches within the version control software. So based on that, you can definitely have lots and lots of different versions up and running just being managed by GitLab. Yeah, definitely. Just wrapping up with the last few questions now. So this is a question from Baskaran. I have the same question on that stuff. We have been requested for function ID from GitLab, how to create the function ID in GitLab? Function ID. I haven't run into any requests like that. Jonathan, have you seen anything happening in terms of function ID? I haven't seen any. Yeah, I haven't seen that as well. Yeah, we probably need a bit more context on that. It's a bit hard to, you know, because I think it's quite specific. Yeah, feel free to shoot us through an email with more details. And then, yeah, we can definitely get back to you on that. Next question, how effective is Metrix performed by GitLab CI? Can you list the types of metrics that GitLab CI is performing? So specifically for the GitLab CI itself, it performs some lots of security and code quality metrics. So it provides a code climate report, a vulnerability list. So that's a vulnerability list both for vulnerabilities found in your code as well as any libraries that your code is using. Found in from static application security testing and dynamic application security testing. On top of that, it provides metrics about what licenses are being used by your project. So it shows you all the different licenses that are being used by the various libraries that you're using within there. And brings all of that into the merge request so that you can sort of see all those metrics are provided to the developer at build time. On top of that, there's some analytics given about the GitLab CI itself, right? There's a CI Insights panel, which has over a period of time, you can see the number of successful pipelines, how many CI pipeline minutes you're using, that sort of thing. So you can get an idea of if your pipeline is getting more or less successful or if you're using more or how that's trending. There's a fair bit of analytics there. There's quite a few metrics there. Just to wrap it up, one final question. At what step is it recommended to run container security tests? So GitLab recommends that we run that in the verify stage. So if we think back to Jonathan's DevSecOps workflow, the new workflow is the shift left in security. So moving it out of that end stage and release and moving it more into the verify stage that happens in every commit. Definitely. Yeah. So look, just to wrap up, this brings us to the end of the webinar. Keep an eye out for the next topic. We'll be talking about closing the feedback loop for a better stage planning, which covers things like better portfolio management through roadmap planning and burn down charts. Granular planning through multi-level epics and how to use how to make use of value stream analytics. So look, thanks everyone for tuning in. I hope you all got a lot out of it as much as we enjoyed providing this information to you. Look in saying that we'd like to hear your feedback about these webinars so far. We'll drop a link in the chat below with a survey link. If you all could fill that out for us, just to let us know, you know, what we're doing right, what we're doing wrong, what you'd like to see in these sort of webinars. Yeah, that'll be great. So again, just a reminder that the webinar is being recorded and we'll send you through a copy of this after the webinar has finished. All right. Thanks everyone. See you later. Thank you.