 Okay, so hi everyone. Thank you for joining today's webinar. We're very, very excited to have you here. My name is Oletha from Goodlap APAC Sales and Development Team. Today's webinar we'll be talking about agile planning and DevOps insights, which will be presented by our Senior Technical Account Manager, Jonathan Lim, and our DevOps Engineering Solutions Architect, Rob Williams. So just a little housekeeping before we get started. This webinar is being recorded and the presentation and the slides will be emailed to you after the webinar has finished. Okay, so if you have any questions during the presentation, please type them into the chat box in your Zoom control panel below. I will compile them during the presentation and we give some time for John and Rob to answer your questions at the end. We also have a couple of polling questions throughout the session. It will pop up on your screen and all you need to do is pick an answer that's most applicable to you. All right, so now let me introduce our presenters today, starting from Jonathan Lim. So, Jonathan is a Senior Technical Account Manager here at Goodlap. He's based in Singapore. Prior to joining Goodlap, he worked in the big data analytics and application monitoring space. Having seen the cause to rectify production issues, Jonathan wants to help organizations adopt DevOps best practices to face their problems earlier and quicker. We also have Rob Williams joining us today from Sydney. Rob is an experienced DevOps engineering consultant who in the past has worked with large enterprise organizations to build and deploy web applications, as well as through our digital workflow transformation before joining us here at Goodlap, where he's been helping to bring modern DevOps practices to more companies. So without further ado, let's begin. Over to you, Rob. Thanks, Letha. So we're going to start straight up off the bat with one of those polling questions that Letha mentioned. So the first polling question that we have is, what flavor of agile methodology are you currently using? So there's a couple of different options here. We've got Kanban up there. We've got Scrum. We've got test-driven development. And there's a couple of miscellaneous options for other people. So we're going to give it about a minute here, between 30 seconds and a minute to see what sort of version of agile you guys are using. As the results come in, it's seeming like the majority is Scrums or about 40% Scrum and 24% Kanban and then reasonably even split among the rest. And with about 80% of people, 90% of people reporting now, again, it's continuing on. And the vast majority is Scrum and Kanban. And that's not surprising. That's what we see a lot in the market. And it's where the Goodlap agile planning focuses on as well. So now we've got that. Let's end that poll and move on to the next one. So the next poll we've got here is asking what tool you currently use for your project management. So this is looking specifically at the tooling. So we've got Jira and Confluence and already they're off to a flying start as expected. But then the other ones we've got Asana. And if you're already using Goodlap agile planning or if you're using another tool, your Trello's or something like that, let us know. So we're getting people responding a bit quicker now. So we're going to close this poll off in a few seconds, but we're getting about 40% Jira Confluence, 40% others, and then about 18% Goodlap with one user being an Asana. So it's interesting information. It's, it's pretty interesting that the 18% of people here are already using Goodlap. Hopefully we can show you something about how to use Goodlap that you didn't already know. And for the rest of you, we can introduce you a bit more to what Goodlap can do in this space. So before we get into the actual capabilities, I want to talk about a couple of strategic imperatives that lead towards Goodlap being a really good agile planning tool for your DevOps workflows. And the first is this concept of concurrent DevOps. And this is really about breaking down the silos in between your teams so that they can all work together in rather than a long sequential line where you're handing off work from one team to the other. And you have these silos of DevOps practices, right. So your one team might have some DevOps practices, and they might be very good. But then because they have to hand off to another team with their own DevOps practices that are different. That can slow things down. And what we really need is concurrent DevOps platform and DevOps lifecycle to deliver an end-to-end capability. And one of the biggest roadblocks to concurrent DevOps is the tool chain tax. And this is where you have all of your different tools like your Geras and your Jenkins and all these things. And they're all integrated together, but you still have to hand off between these tools. And oftentimes when you're in different teams, different teams use different tools. Pardon me. Different teams are using different tools. And so it leads to a more complicated interface, a more complex visual language and context switching for developers, product managers, and everyone involved in the software development lifecycle as a whole. So what GitLab really offers is that single platform that allows all of the different personas to participate in the software development lifecycle. And that's really important when you're looking at the analytics that go into every stage of the DevOps lifecycle, because even if you optimize at one end, say your create or your source code repository, you still need to be able to have insights into your configure and into your application platform as well as your project management. All of it comes together into a single platform to deliver the end-to-end DevOps lifecycle experience. So what I'm going to focus on is how GitLab works in this first branch, this product management way, looking at the management plan stages and how GitLab enables the agile planning capabilities in the DevOps lifecycle. So the first part of that is going to be how we organize our teams, right? So there's a very hierarchical nature here with groups and subgroups. So this is where you would store your, like, how you would organize your team members into their business units, their functional teams. However you split up your team members or your projects, this is how you can accomplish this with the group subgroup hierarchy. And then within any of the groups or even at the base level, you can have projects. And this is where you store your source code, you'll have your pipelines, as well as planning specific work for that specific code. So now that we've organized our teams and the people doing the work, what we really need to look at is how we can define the work that those people are going to be doing. And there's two different levels of that. Well, two, two and a half, because epics can have subepics. So epics are a higher level. They tend to be capabilities or long running pieces of work, things that are going to take you a little bit longer and have a bit more meat in the, in what you need to do. Contrasting with that, you have your issues then, and these tend to be very small and discreet pieces of work there, your user stories and your functional acceptance criteria. So now that we've defined how you how you do the how you define the teams and defined the work. Now we need some way to plan out how the work is going to function. And for epics, we have what's known as a roadmap. And the roadmap is basically a Gantt chart where you can see all of the epics and the subepics on and their start and end dates displayed as a Gantt chart so that you can see when lots of capabilities are going to be lining up when you might have lots of releases coming out or whenever there's going to be a bit of a bottleneck for when your features are going to be released. When it comes to the issue level, we have what's known as milestones. So the most common usage for milestones is around sprints. So because these are for your small discreet pieces of work, you can use milestones to categorize issues. In that way, so so that you can go from one sprint to the next sprint to the next sprint and you can see what was released in any given milestone. So we've organized our team, we've defined the work, we've planned out the work. And then when you're doing all of that work, it really goes into the project level. And this is where you see the code, the code reviews, the discussion about individual problems and pieces of work. It all exists at that project level. So if we bring all of that together, we see GitLab's agile planning structure and the capabilities that can be driven through that. So this is the, what it does is it provides the ability to coordinate your teams onto the same page and provide that traceability that you need throughout the entire workflow. And so here what we've got is just a simple breakdown of how that could look in an example project. So you'll have your upper group, your company, and then you'll have individual staff. You could have individual storefronts and they'll have their own epics that they're doing because they have their own needs and their own requirements. And then underneath that, at the project level, we have a project called billing and then that has its own issues, which is where you're actually doing the work that relates to those epics. So when we look at issues and epics, one of the biggest differentiators that GitLab issues and epics have are labels. There's a couple of different types of labels and what they do is they basically define the most important metadata about your issue. So you have your epic and your milestone defined and these let you define what feature is going towards or the time period that you're going to release it. But then there can be a lot more things that can be found and decided about individual issues. So you can label them with any sort of description that they're entirely customizable, both at the group and the project level. And the labels form the backbone of and the most important part of GitLab boards. So here we've got some examples of how boards get generated based in around how GitLab uses them in the quality team. So with the GitLab boards, there are three different ways that you can create lists of issues to visualize how the work is going. The first is the milestones. So this is really useful for scheduling issues and categorizing them into different sprints so that you can see one sprint, two sprint, three sprint, and you can see which sprints have too many issues, whether you're using a point space system or just the straight number of issues. You can see where you're going to have that bottleneck of a lot of work waiting to be done for a specific milestone. The next dimension you can use is the assignees. So you can directly create lists of issues for individual users so that you can see which team members have a lot of work on for the current sprint. So in that way you can sort of, you have your scheduling of the work and then your scheduling of the people. And then once you've gotten past the planning stage of the work and you're actually starting to do the work, you can use labels like we discussed earlier to create individual lists of issues that are based that contain that label. And when you drag issues from labeled lists, the labels get taken off and added as you enter and exit the columns. And that way it lets you do your workflow boards so you can go ready for dev, developing, ready for test, ready for deployment. However you have your workflow, you can create your labels in your own way. And beyond the individual workflow, what it really does is it provides that flexibility to allow teams to do whatever they like with the labels. So what you can see with the GitLab quality team here is that they've used labels to create different priorities, P1234. And in that way they can see when they've got a lot of really, really high priority issues that they need to be working on. And with that I think that I'm handing over to Jonathan now quickly. Thanks, Rob. Can you guys hear me all right? Okay. Yeah, so let me... Alright, I moved in to present a view. Can you see my screen? Alright, Rob. Okay. Yeah, so I think Rob kind of talked a little bit through the planning stages of where GitLab's at in the platform. And it's more like a segue or like moving into the other component here. So just to begin, how are you currently measuring and collecting data on your people, processes and tools? And I know there's like GDPR and all that kind of stuff, but we're not talking about like collecting privacy data, but more like, you know, are your tools being monitored by like APM or like log monitoring solutions? Are your people monitored by certain metrics or KPIs? Or even so, like your processes, like your end to end time from like time to value and so on and so forth. Right, so I see that a lot of people are currently not monitoring a lot of these things at this point, which is actually interesting. And I hope this second part of the presentation will be really useful for you and kind of give you an idea on like what we at GitLab kind of believe in terms of like monitoring some of these things at your organization, which can help you to make better decisions. Okay, all right, so I think we got about 90% of the votes and the poll here. So let me just share the results. So yeah, we have about 75% of the people saying that they don't really measure a lot of these things and I think hopefully I can convince you today that it's quite important, right, to measure some of these things. Right, so that brings me to my topic which is insights, right, so GitLab insights, the idea behind it is if you can't measure it, you can't improve it. And what do we mean by that, right, so Gardner has come up with a new market category that's called the DevOps value stream delivery platform. And that's where GitLab is currently developing ourselves or trying to mature in this space at this point moment. And in short, I think what we are trying to do here is really to provide visibility, traceability and observability into your workflow. Right, so not having it like a black box where you're like, oh, where is my money being spent. So let me give you a scenario over here. So imagine that you are a, like a team lead or you're like a director of DevOps at your organization. And you are given a budget by your finance department or so and so forth of $100,000, right. So out of this $100,000, where do you spend that $100,000. So you know that in your previous year, you had issues. Some of your development processes were a little bit slow, your projects were kind of running over time, over budget so and so forth. But you're not exactly clear about where do I need to invest in for my next budgetary year, such that we can actually gain the most impact right get the most impact out of it. So do I invest in more compute because you know I'm not running my CICD tests or my pipelines frequently enough. Do I need to provide more infrastructure. So maybe my GitLab platform or even if you're running GitHub on prem or even some of the other things. Are they a little bit slow. So do I need a HA kind of a solution. Do I need kind of a geo kind of solution, which allows me to you know access it from multiple regions. Do I just need to hire more developers right so maybe your developers are being hammered right now. There's a lot of your developers are just working day and night and they're really just not being able to cope. Should I be having longer sprints in this case if you're using agile development and because of having longer sprints does that also mean I need to hire more develop more project managers. Always security a concern right so when your decision making I guess that's the part where you need to be concerned about but how do you make these decisions. So I think that's where GitLab where we believe that some of these decisions, some of these tools can help you to make your decisions a bit better. So right now we do have approximately 20 different reports that are available and dashboards are available but of course today I'm not going to bore you and go through with you all 20 different ones of them. But I'll just focus on a couple or not a couple but actually just eight dashboards over here to give you a flavor and idea. So if you need clarifications or you do want to actually talk a little bit about it, just reach out. Let us know. We will definitely start. We can have a separate conversation in detail on some of these. So first and foremost, starting from a high level, some of these executive insights. So I'll go directly into the first one. Value stream analytics. So what does value stream analytics really means it's time to value. So in the moment of ideation, when you come up with an idea, and then you're like, hey, you know, I got a project that I want to do to the point where you decide that that is that that it comes prototype is a prototype comes out or something that you can push into production. That's your value stream right so how long does that take from you to come from an idea all the way to a product at the end go. So in between, of course, there are the different steps, as you can see here that issues plan code test review staging and so on so forth. These are the ones that get that we believe are like the default stages in terms of a software development lifecycle. By the same time we realized that maybe different organizations operate differently. So as soon as early as 13.x that we have. We did realize that it might be actually really good if you could define your own stage. So we added this new functionality over here called at a stage, so you can actually define a new stage you can put your start your step event and then your end events to actually define these stages accordingly. So what does this do helps you find out where your bottlenecks are. So you know that hey, you know, we are spending a lot of time in a plan in maybe, you know, our staging environments right so you got you can actually focus your attention or focus your resources on a specific stage. And, and, and, you know, out of that $100,000 in that sense you can then put a bigger chunk of that towards that project. Next thing is CI CD analytics as the as the name suggests it basically gives you a overall pipeline run duration in terms of like your your week months and year. It tells you your success rate I think that's basically what you really want to measure in terms of your CI CD pipelines, whether they are failing whether they are successful. And then that's not just it right so given this form of information what can you deduce from it. So first thing is that if you see a lot of failures. What could it be. I mean of course you need to do a bit more like deep dive into it but it could be the case that your your your runners are being overloaded. Right so your runners are being overloaded then there are a lot of failures you're not having enough infrastructure that that's required. Or it could mean training right your developers are not being trained well enough in the sense where they are not able to write proper CI CD scripts right. So in that sense that's something that maybe you want to invest in having more training for your developers to actually write better, you know, your pipelines and all. Right so this gives you an idea about how you can actually spend your money again to invest in your team. So the third thing I think Rob earlier mentioned about where we're talking about epics and one of this dashboard that I think really summarizes or helps you to visualize all of these epics in a in a proper way. It's the roadmap dashboard. The roadmap dashboard helps you to organize it and helps you to visualize it across time on whether certain epic certain like features when when would they get pushed into the product itself. So say for example now that we are at GitLab the version that we're running right now is I think 13.5 also. So is that you can actually see and I'll show you later as well in our demo. What are the features that are being slated for your next version. So your 13.6 13.7 and that gives you that credibility and you know that that transparency to your customers or even to your management to like hey you know these other things that we are going to be spending our time on for the next year for the next month or so and so forth and because of that we need this certain level of investment for our teams. It helps you to also I understand are we building the right things at the right time so are these features in the next release really important or can we actually push those features into a further release later on because of like the lack of resources and manpower. Right, so these are like things that help you to make these decisions. So first but not least, we do have the DevOps score. So DevOps score it helps you in general to measure your organization's maturity in DevOps adoption. So this is more like more from a GitLab definition of DevOps score. And what we do is that we break it down into the different parts of it which is like issues comments milestones bought so and so forth as you can see in the screenshot. So what we measure is that how much how are you utilizing all of these features and whether these features are able to whether these features can help you. We understand that in the industry level, there is the Dora metrics as well and that's something that's on our roadmap. So Dora metrics is something that's more industry wide in the sense where they do measure on certain value such as deployment frequency lead time for to restore services and change and change failure rates. So some of these things are actually something that we are actually moving into our next iteration on. We don't have a timeline on that yet. But we are assuming this is something that's going to happen next year. And then we'll input all of these like soft industry wide best practices into how we measure your DevOps adoption at your organization. Okay, so look out for that that should be coming around next year or so. So that covers basically the executive insights and I just want to touch quickly on like the four different insights for productivity developer operations and security. So first and foremost productivity insights. What you can see is that you have dashboards over here. So these dashboards are able to give you help help you to see like the number of bugs that have been created over time your merge requests regression and track and how these are tracking over time helps you to see whether in a specific month or so is there a lot of issues and then you can drill down into like, Oh, hey, you know, maybe there was a new new feature that was actually a release during that time. And this feature actually created a lot of issues. So maybe we do need to put a bit more attention on that. Developer insights contributors. So you can actually see in terms of like your overall commits to master and to buy each of these users. So this is not a tool to actually track whether your developers are slacking, but rather it's kind of a tool to understand whether your, your developers are actually being overworked. So if you actually see a particular developer that's, you know, committing too much you don't want to burn your developers out and therefore it gives you an ability to like hey you know this guy maybe it's he's really doing a lot. Let's promote this guy or even so it's like hey this guy is doing a lot and he's the only one a project. Maybe we should hire a few more developers to actually help him out. Operations inside gives you a basically a very high level overview in terms of your environment, whether your tests are passing your pipeline status and your last deployments. So it gives you an overall idea of like, you know, overall in terms of your, your architecture, infrastructure, whether they're healthy or not. Of course this is a point in time. And then you can always do a little bit more customizations with creating Prometheus dashboards and and and so on and so forth but this is kind of our first iteration of like our operations dashboard. And last but not least security insights. Right. So as I mentioned earlier, security is actually a very big part of it. And we do have like we have done another webinar by one of our colleagues by summer as well. In terms of like the adoption towards like the DevSecOps methodology at your organization, but having these sort of dashboards give your, your management or give your team anyway, an idea on like hey how are we doing in terms of like managing our security risks, our vulnerabilities, our code dependencies and so and so forth. Right. So this dashboard really gives you that high level overview and knowing well should we be focusing a lot more on security or do my team needs a lot more training in terms of like delivering more secure code in that sense. Right. So I covered eight dashboards and I think what I'm going to actually drive across the idea is that these are all just metrics that you're collecting, but collecting metrics don't mean anything if you're not going to feed it back. So the reason why we kind of came up with this topic is that we hope that this is actually a loop or cycle back in terms of like once you get all of this information. This information should help you to actually plan your sprints better to help you to develop products better in a better way. Right. So moving back into what Rob has mentioned earlier as well. Hopefully this information that you have collected over here will then help you to you know create those milestones better create those epics better in a in a more granular way and make your decisions better in that sense. Right. So that's a high level overview. And we'll move on to the demo. So Rob, I think we'll start to start this off and you'll go through if you like soft the workflow of how we actually use a stage planning. Yeah, cool. Thanks, John. So I should be showing my screen now and you should be able to see some GitLab user interface. I've gone ahead and created a company company incorporated and set up some some groups within there so we've got our marketing team we've got our infrastructure team we've got our BI business intelligence team, the app dev team and then a general CI templates project. And then underneath that we've got individual projects and subgroups within those teams that allow us to get more specific about what those groups and projects are actually doing. So if we take a look at the infrastructure group here, we can see that we've got a multi cloud tendency here we've got Google cloud where they've got an application platform and some network configurations, as well as some some things in the in AWS. And because because this is focused mainly around the planning, what we can do is we come in and have a look at the epics we can see we've got one epic that's currently underway, and that's our scaling the cloud application platform. So we come into that we can have a bit more detail. So there's there's not much description here, but you can you can put anything we liked in them we can see all of these four issues that have already been created. So, within the infrastructure for AWS infrastructure AWS, as well as for network configurations or application platform. So you can see all of the work that needs to be done under this epic within the epic itself, as well as any discussion that's been going on about that epic. If we jump into any one of the. Let's let's jump into the AWS project and take a look at that a bit more closely so here we're at a specific issue, but if we come back out to the Amazon Web Services. And we look at the issue list, we can see our two issues here. And we come over to the boards, I've gone ahead and it must have been in the other projects, my bad. So we come back out to the infrastructure, we go to Google Cloud. Then we should be able to see a board hopefully. So I'll find I'm sure I'll find the project that has my my already created boards here eventually. No, if not, then that's fine we can create them as we go it doesn't take very long and the boards are very flexible. So if we come over to this board we can see that it's created a development workflow board with to do and doing already. But before we start actually doing these issues we need to plan them out. So if we go ahead and create a new board and we'll call it sprint planning. So you can see I've created a few boards in my time already. And I don't think we need the closed list for that. So we're just going to create that board straight away. And by default it's added those two lists but we can go ahead and remove them. And now we've got a blank board. And if we add our lists for that for our milestones, we can add in some of our pre created milestones. And I think that before we update any network configurations, we probably need to update the Terraform script. So let's go ahead and put that in sprint one and we'll put the network configurations into sprint two. What we can do then is we can create another board. And again, I don't think we need the closed one for this and we're going to call it team assignments. This is where we're going to assign some of these issues to individuals. Right, again, we don't need these boards, these lists, so we're just going to go ahead and remove them. And we're going to add lists for each of the assignees. And you can see that me and John are members of this company Inc. Where we're here and we're ready to work and upgrade our cloud platform. So we're going to add columns in for each of us. And then we're going to assign them to individual people. So you can see that already that that's assigned that issue to me and the other one to Jonathan here. So now if we come back to our development board, now we've got a little bit more information on these individual issues. So now what we can do is we can edit this development board and we can limit its scope to a specific milestone. So if we say sprint, we say started milestones and we save that. Then because that sprint one starts today, then it's only showing issues from sprint one and Jonathan you're lucky this sprint you don't have any work, but I'm going to go ahead and drag this one to doing. And so that's that's just how a general sprint planning could go within GitLab right so we even did it from from scratch from a blank project with no boards we made our sprint planning board our team assignment board and now we've started development. So with that, that's the plan demo I think I'll hand it back over to John and he's going to take you through some of how GitLab uses our insights features. Yeah. Yeah, just give me a moment. All right, so Can you see my screen all right? Okay. So I'll just go through a couple. Again, due to the lack of time. So first things first is I think our DevOps report. So this is an example of our DevOps report over here. Let me zoom in a little bit more because it might be a bit too small. So over here what you can see is you can see like how we actually define some of these things. And what we actually how do we actually get these informations is that or how do you get this lead information is basically when you turn on the ping test as in the ping. So it actually sends some of these information back to our GitLab servers. And it basically compares them against all of our GitLab customers as well. So in terms of adoption of a certain certain feature also. So not only that do we just give you numbers and we don't give you any suggestions right so over here if you were to have like questions or like oh how do I what do milestones actually mean you can actually click into here. It would then give you like an idea on like what this milestones how you can do it. How do you actually create the ones so similar to what like Rob was doing just now in terms of a demo. This gives you the documentation how do you actually adopt milestones at your project. So not only that we do also include certain types of articles so for example it's like why are milestones important and then we also give you like external links that are not GitLab related but more like from a industry level what do people kind of assume these things what what what are the benefits of having adopted milestones also. So this DevOps report is really I'll just our first version of it we are definitely going to move into a next version very soon incorporating like like DevOps like like all the Dora metrics and so on so forth. Okay, so yeah. The next thing is kind of giving an idea in terms of a insights so just now and I when I mentioned over here this is the project for GitLab.org or our GitLab page for our web platform so over here you can actually see like across the months how many high priority tickets or issues that are being created over time. Of course as the company starts to grow and a lot of more people adopting GitLab we then start to have higher priority tickets or like the tickets in general starts to increase over time. So you can also see like the bugs created over time by severity and you can actually change it into different dashboards or so. Okay, how do you create this dashboard so there is a YAML file that you can actually look at and you can actually create that there is sort of documentation based on that if you're interested to know just Sorry, just going to Google like GitLab insights and you probably get to see like the steps so it gives you like all the metrics that you can create your dashboards on even if you have certain like you created your own types of labels you can actually create some of these dashboards based on the labels that you have you have actually assigned to your project. Okay, so that's where issues insights are really useful and that's how you see certain trends and the idea behind it is not only just to see the trends but to actually take action from these trends and say hey you know over here in terms of April there is a there is a slightly higher amount of issues during the month of April so drill down into that see what's wrong in during that month or so and see whether you can make more decisions based on that. Security dashboards so this is a high level security dashboards. So this is for our GitLab platform as well so please don't take screenshots and you know try to you know mess around with our platform. But a lot of these things that you get to see here you get to see like oh we have certain critical security things that are happening. There are some of the high, medium and low security threats that have been here so I think so far a few of these ones you can you can actually take a look at and your security team can then pick up on that and you know and show that you are doing the right thing or like focusing on the right kind of security that you have so that's a very high level that's for vulnerability you can have like for your license compliance whether you're the projects that you're working on what are the project are you license compliant or is there like investments that needs to be made to actually become compliant by purchasing some of these licenses. So that's from a security perspective. And last but not least is kind of the apex so let me zoomed out a little bit more because it's a bit hard to see. So personally for me I'm actually involved in the product development for GitLab as well in terms of like advanced searching. So this is something that I actually look at quite often because I'm helping some of the developers to actually develop better search algorithms in terms of like where GitLab is at. So one thing first things first is that I would highly suggest using a label because you might have a lot of different milestones that are available. And if you're looking at GitLab like if I were to remove that label it would actually lack my computer because GitLab has so many milestones that we have. But what I want you to see is that over here you can see that there is this milestone which is like 13.4 13.5 13.6. And over in 13.6 over here you can see that these are some of the enhancements that we are basically going to be doing in our next version of our GitLab when we do release it. And over here I think Rob has mentioned as well if for example you have SAP epics within the main epic or so you can actually see that and how they break down. And see in terms of completion rate based on your own you know thresholds that you have set for these milestones. So this is very important for you in terms of like planning for your organization and helps you to see overall how your organization is performing and what your roadmap is and gives that transparency to your customers as well. Okay, so that is basically it. Again, this whole session is not supposed to be exhaustive in terms of giving you an idea like going through every single feature in GitLab but these kinds of like gives you an idea in terms of like the plan as well as like the analytics components of what GitLab can offer and how do we make use of these tools in a day to day or like organizations make use today. So with that, I think I'll hand it back to Alita who will kind of go through the questions. Yep. So, we've got a couple of questions here. Let's go through it one by one starting from Saurav Sharma. How can we do monitoring of mobile apps in GitLab, something like New Relics or Google Firebase do. So John would you like to answer that. Yeah, so, so yeah, so just a bit of background I did come from an APM company previously as well so I used to do a lot of these kind of mobile app monitoring. So I'll be upfront with you and say that GitLab we are not there yet in terms of mobile app monitoring. Even for our web monitoring we still use like open source kind of APM tools such as Yeager, which and we are quite, how do you say technology agnostic in that sense where we don't really, it really doesn't matter what kind of APM tools you would monitor. We do have mobile app scan mobile development scanning though. So that's something that we released recently in 13.5 in terms of like security scanning. So I think that's something you can take a look at. But around the idea of monitoring, I would say still focus on the companies that are good at doing these these things. And then, you know, you can incorporate that as part of your like CI CD process when you're building up your your your files also. But yeah, we do we are we are not that mature in that mobile app monitoring as of now. Yeah. Okay, thanks Jonathan. Moving on to the next question by Geeta. So for planning, how can we include company provided holidays and people leave plans. So Rob, would you like to answer this one? Yeah, for sure. So we don't have any anything specifically around creating holiday plans or anything like that. One of the best workarounds that I could think of though was if you if you were to create some sort of an issue that said that on leave and then assign that to a person, and then put that into the sprint you could see that when they were going to be on leave and use the due dates and that sort of thing to work out when they're going to be back just so you've got that visual reminder within your project management tool to remember that the person is actually not on leave. So get labs really focus more around what people are doing and not whether they're like I like the holidays and that sort of thing that they're doing. You'll notice that that they they don't have any activity within get live issues or anything like that while they're on leave though so there's not anything specific but there are a couple of workarounds that you could get through. Okay, cool. Moving on to the next one by Dave, Dave Huang. Can the CI CD analytics compare each commit and when there's a spike of process time, then it can send out some sort of notification then maybe tech lead can involve and check that commit. John maybe you could answer this one. Yeah. Yeah, so I think I get where you're coming from I don't think we are there yet as well in terms of being able to take action. So, yeah, at this point, so a bit of background is that I used to work in more of like a security background security as well where they have this, like in security tools they have this idea of saw as OAR, where you basically have an incident and it automatically does certain things such as like sending incidents out. I don't think we are there yet in terms of get that right platform. So right now it's mostly more from a. Yeah, I think it's still quite early on in terms of like we are still at a page where we can actually see information from that point onwards. But what you could potentially do is of course, you can potentially build your own custom solution where you can actually use github API to pull out certain data, and then using some form of solutions maybe like a, like a kind of stack to actually build certain incident rules on top of that. Yeah. So, in short, not there yet. Yeah, just just to blow on top of that like in the CI CD analytics graphs that there is like a little bit of functionality there for that. So, one of the things you can see is a graph of the duration of the pipelines that have been run on the last 30 commits, right so pipelines get run every commit. So you can see the duration over that the last 30 so that you can see the spikes over that, as well as over some of the longer periods like over a week month or year. But there's not that as Jonathan says right there's no notification or mechanism for making something off that it would have to be a manual thing or a different text stack that's been created and integrated with the good lab API to get that. Yeah. But if you if you're looking at the graphs there is something there for you to see. Yeah. Okay. Thanks Rob and john. So next one from Prashan Kulkarni. What level of GitLab usage knowledge is expected from a scrum master to be able to set up the GitLab for a project. So Rob or john who wants to take this one. Yeah, I'm happy to answer that one. I think it's I think it's a really interesting question. And it's going to change depending on your team right. So basically like what we've shown today is sort of where I would I would think that most scrum masters would need to be right having the ability to manage the members of groups so that you can see your your team members and then setting up milestones and creating the issues and then looking at the boards. So beyond that there's there's not a huge amount of not like usage knowledge expected from a scrum master. Despite the fact that GitLab has capabilities to go way beyond that right. So we've just looked at the plan and manage stage beyond that you have your source code repository with merge requests. You have CICD pipelines. You have integrations with Kubernetes deployment environment stashboards. None of that is needed for a project manager. That's more around like the operations and the software developers. So really it's just about being able to plan your work so similarly right like you just need to be able to look at the epics and be able to define all the work and then let your team members know where what that work is. So that then they can action those issues and take it all the way through the DevOps lifecycle because there are lots of different teams that are involved in the DevOps lifecycle. Cool. Thanks so much Rob. So the last one from Colipara Gupta. Is it possible to label the pipeline with past percentage. Yeah, so I think I understand where you're coming from in terms of the like, because right now it just shows like all and then success right it doesn't have to show a percentage or so. That's actually a very good question so as in that's a very good. I would say it's a it's something that we should definitely look on what I would suggest as I understand this is kind of what you're looking at and it just kind of give you numbers in terms of in terms of rather than percentages. So yeah, I think that's a really good idea and I would suggest maybe you can actually raise an issue on on something like that. And then I think our developers will look into that yeah but yeah good point yeah I think that's something that would be very useful for a lot of teams as well. Okay, cool. So we have another one from Sarah off again. Is there a way to hide source code from reporter user. I would like to not show the code to our testing team. So John or Rob. I'm not 100% sure that this is correct but I don't believe that we can change the viewing commissions there so. Yeah, the, the thing with the testing team though is that like, like, they don't need to necessarily. So what you could do then is create a board at a higher level right at a group level, and then that's where your testing team can work, rather than in the actual project itself. So, in that way the the testing team is a is a separate entity within GitLab and has its own workflow and that sort of thing. They can create their own issues and have their own boards and work in their own way. And in that way they'll be entirely separated from the process of actually creating the code. And then you can create issues within the testing team board that is then like, please test my app we need this this this and this tested, and then the testing team can work that through their workflow. Yeah, sorry, John. Yeah, so I because while Rob was talking I was kind of like, you know, doing a bit of research on that. So yeah, I think within a single project. In terms of like the reporter developers maintenance also you can restrict the viewing on that. So I think what Rob kind of idea makes a lot of good sense in that sense that you kind of separate them in terms of project and then you can have that role based access control on two separate projects. I mean, within GitLab also you can kind of do like a cross project functionality where you can actually run a certain pipeline in your development team which then triggers another job in your pay me testing team also so your testing team only just looks at their project which is just purely on test. Yeah. Okay. So yeah, we've got another one from Venkat Suresh. So in branch level access, can we restrict the teams. So, so unfortunately we can't we can't do that at the moment. The membership is to an entire project rather than individual branches. So once you have membership of a project, then you have membership of all the branches. I mean, what what you can do though is restrict who can push and merge merge requests for specific branches by using protected branches. So by default in your repository master is the protected branch. And so only people who are have a certain permission level I think it's maintainer are allowed to merge merge requests into that the master branch, and you can set that up for any branches you can unprotect master if you wanted to. It's it's a for for any branch, but you can't specifically restrict members from being able to view a branch if they're a member of the project. Yep. Yep. Thanks. John, anything else you want to add. I know. Yeah, that's exactly. Yeah, same thing. Okay. Okay, cool. So since we're running out of time. Thank you so much, john and Bob for a very insightful presentation. And once again, thank you so much everyone for shooting in today. We hope you found it valuable. No matter that the presentation will be shared with you via email after, you know, a couple of days. So before we go, I would like to announce that we will be hosting a live virtual hands on workshop on December 8. I want to cover how the most effective application development teams leverage give lab to automate their DevOps process and achieve material business outcomes. So keep an eye out for registration details in the follow up email. So thank you once again everyone see you next time. Have a great day. Bye. Thanks everyone. Thank you all. Bye. Bye.