 Hey everyone, we'll just give it a couple of minutes to let everyone join in and then we'll get started. All right, so welcome everyone. Thank you for joining today's webinar. We're very excited to have you on. My name is Timothy Tran and I'm a field marketer in APAC here at GitLab. Today's webinar will cover why organizations are adopting value stream DevOps platforms and will be led by Jonathan Lim who's our Senior Technical Account Manager here at GitLab. Just a little housekeeping before we get started. This webinar is being recorded. The presentations and slides will be emailed to you after the webinar is finished. If you've got any questions during the presentation, please type them into the chat box below on your Zoom control. I'll compile them during the presentation and we'll give some time for Jonathan at the end to answer your questions. We'll also have a couple of polling questions through the session that will pop up on your screen and all you need to do is pick an answer that is most applicable to you. So without further ado, let me introduce to you today Jonathan Lim. Jonathan is a Technical Account Manager here at GitLab and he's based out of Singapore. Having seen how security vulnerabilities or code quality issues in production environments have caused companies to suffer. Jonathan joined GitLab to learn if we could remediate these problems earlier in the software development cycle. Jonathan, take it away. Tim, can you hear me all right? Yeah. Okay, all right, just checking. Hi everyone, yeah, my name's Jonathan. So just gonna start out with a few polling questions, kind of get an idea about like how everyone is and you know, how familiar you are with GitLab. So just for the first question is are you currently using GitLab? So might get in, all right. So I think we've got most of the answers already. So, all right. Yeah, so looks like a lot of people are not using GitLab at this point. Majority of them. So, okay, I'll probably explain it in a way that it's a bit more from like a first time user kind of a way and that was helpful. So for the next one, as the topic suggests, today we're gonna be talking about like value stream management. So if you're using value stream management, which ones are you using? Or if not, I think there's an option that, for the last options that I don't know what it is. So, okay, good. Looks like we have a, so it looks like a lot of people are not, they don't know what value stream management is. So I think that would be a good way because today it's gonna be a bit more of an introductory session about like what value stream management is about and how do we use it. It's also quite understandable since value stream management was, it's a new, pretty much a new segment within the tech stack and companies are now kind of like jumping along onto it. All right. So going on to the presentation, I would generally like to use kind of like an idea of like, how do I explain value stream management? So if you see on the left here, you might take a scenario where you bought a apartment and it's quite dilapidated or it's, you know, everything's broken down and then you go and then you have an idea about what you need to do or how do you want to kind of like renovate your place to look like something that looks like that after a while, right? So that's the kind of end goal in the sense of it. So how do you get from one end to the other end? And I think it's very difficult, especially for some of you who might have your own apartment or your own place that you had and you had to kind of, how do you say, you had to kind of like organize a lot of the things, you had to bring in multiple stakeholders such as maybe your plumber, your electrician, your carpenter and maybe some of your workers who might be helping you with like construction and stuff. And that came about the rise of like interior designers or at least interior designers in Singapore if you are from Singapore, right? So the interior designers basically it's a single source of truth where they help you to actually collect, like collect all the information, help you to put it into a single data, data like a single data platform where you get to see all your problems, they help you to organize all of these things, give you that visibility overall and help you to kind of like make things a little bit easier. So I guess in a way, that's what value stream management platforms are. So by Gartner's definition, value stream delivery platforms help organizations simplify and manage somewhat like a designer as well. So the idea behind it is to provide that traceability, visibility, observability into your entire workflow, specifically in this case where we are talking about is your software delivery lifecycle. So as part of the DevOps report that Gartner has, these are kind of like the main three problems that we actually see. So first and foremost, multiple point solution. So as you know how, because DevOps kind of like came about due to like sort of like the agile movement towards like software delivery, a lot of different companies are actually doing like a small different components. So you have a company that does like source code management very well, another company that does CI very well, another company that does security very well. What happens in this case is that because of that, that's kind of the increased complexity because you have so many solutions out there and all of these solutions have their integration points which may break when you kind of have to upgrade or you have to kind of fix a lot of these things. There's also the management issue of it, how do you manage it? There's the idea of like having to manage all your logins. So for example, integrations with your LDAT or your Kerberos or your like single sign-on and all that. Second point struggle to reduce mean time to repair or MTTR in this case, there's a lack of visibility across the board because you have so many tools, right? So you're not really sure for your developer, where are they getting stuck at? Is it from issue management or is it they're getting stuck in their development process or is it that their CI pipelines are running slow? And what are the constraints, right? So are they not able to scale horizontally well enough when they have like not enough compute power or is it the problem where they have problems with like fixing their storing their artifacts in a way or they have problems with their delivery in terms of like multiple, multiple cloud vendors and so on and so forth. Last but not least, scalability and security, especially in this time and challenge of like remote working, this has become a bit of a problem because a lot of people are using VPN, a lot of people have to, security has become a very major concern because data is being transferred over the internet and security becomes a big part of it. That's the infra and operation costs towards it. How do we manage it in a way that it makes sense, especially for multi geographical organizations that span across multiple countries? How do we manage that in a secure way? So Gartner gave us some idea about what is required and these are like kind of like the key highlights or key milestones that I think would then set a software delivery platform that supports VSM or in a well, in a good way. So during the plan and create components of it when you're dealing with your issues, when you're actually creating your code by actually committing your code, integrate and verify where you have all your code basis verification, whether is it like your code quality or having your security scans, you'll deploy and operate and your monitor improve. These are all of the things that are very important for you to manage your software development lifecycle properly. On top of that, it has to have like the security and compliance as was mentioned earlier on allow teams to collaborate properly, having APIs or extensibility, so that if you need to actually export a lot of these things to a external VSM tool or even your internal VSM tool, that might make things easier and then governance and access towards it. All right. So GitLab has kind of like taken some tips or like some feedback from this thing and we came up with something that is similar in that sense. So across the 10 stages of our development lifecycle from manage all the way to defend across the multiple teams such as product management, developers, quality assurance, security, operations and infrastructure, we wanna make things easy for you. So in the sense of having a single data storage so everything is stored on a single platform, single permission model. So you don't have to have multiple tools and trying to integrate all that LDAP and all their governance and security because of that single interface and that collaboration. So I think today we're not gonna be, it's not a sales pitch. This is more like trying to get you to understand like what the industry is trying to do and how GitLab as a company is trying to align to some of these values, right? Another thing that we do have is platforms. So GitLab has invested a lot of effort into our analytics and insights tools. So right now, as we speak, we have approximately over 20 different types of dashboards available on the tool itself to actually give you some insight into different components such as like your executive insights which we will be talking a little bit more about later and including for more granular breakdowns in terms of like productivity insights, developer insights, operations and security insights. So I will not go into details that are quite a lot of resources available online into talking about each and every type of dashboard available, but today I just wanna focus a little bit about the executive insights because we are kind of talking about value stream, right? So in GitLab, we have a dashboard called Value Stream Analytics and what it is is that helps you to basically identify some of the bottlenecks in the development process. So as we mentioned, there are the multiple stages available as part of the entire software development. One of the things that, so we start from issue and then we go to plan and then we go to code, test, review, staging, so on and so forth. So this is kind of like a high level default stage across a software development life cycle, but we do realize the idea that maybe different teams and different organizations actually manage your software development differently or you might have more granular tasks. That's where we have the ability as of, I think 13.6 or 13.5, a couple of versions ago that we have the ability to add new stages, right? So adding new stages allows you to define the different stages in your software development life cycle as needed be, allowing you to actually have more control into how you want to actually manage, monitor some of these stages. So VSM or Value Stream Analytics in that sense is basically a time to value. So how do we define time to value? That's entirely up to you, but how I think a lot of the industry people kind of define it is from the moment of ideation. So when you come up with an idea, so for example, if you come up with a feature within your, for your project to the point where it's actually deployed into production or in a UAT environment. So that's entirely up to you, right? So that's kind of like the idea behind time to value and how your organization defines it is how you might want to actually do these things. There are a couple of things in the backend that we will talk about and I will actually show you in sort of like a demo or like looking through some of the dashboards that we have, but there are some of the key things that you need to enable within GitLab if you were to choose to use these features. Next thing is road maps. So what road maps are is that it's a kind of a timeline for Epics. So Epics, if you are familiar with the GitLab terminology or if you're using some other Kanban-bought technologies out there such as maybe your JIRA. You get Epics are basically a collection of issues or problems or workflows that you might want to track at a high level overview and then helping you to answer a bigger question. So maybe one of the things like a typical Epic would sound like would be trying to improve my front-end web performance by 20%. So that's a high-level Epic and within that high-level Epic you might have more granular tasks such as changing my front-end web server to Nginx or like changing a framework to a certain different framework. So these are like kind of more granular tasks that answers a bigger question. So this is kind of like a way of how you actually time your value and because of the ability to kind of see it from a timeline perspective for each of them. This is how this would actually help you to actually get your value a little bit faster or help you to measure your value a bit faster. Coupled with the idea of milestones where in GitLab how we actually use it today is having very specific milestones such as like releases. So every month on the 22nd, we have a release. So we have a milestone release every single month and how does this Epic actually coincide with a lot of these releases is something that we are always trying to figure out. So these are all some of the things that we do have currently in GitLab. By the same time, we are always looking out. And again, like mentioned earlier, we are not today, we're not just going to be talking about GitLab but kind of like that, what is the industry kind of looking at? So what is next? So over the past few years, founded in 2015, a group of people or like a kind of a group of companies came together to come up with this assessment called the DevOps Research Analysis or what is known as Dora. In 2018, Google then acquired this group of people or like the kind of like is managing this group of people. And the basics, the basis behind it is that they want to kind of come up with a standard or some of the best practices that comes with it when it comes to assessing your DevOps health within your organization. So across the years, Dora has came up with these four metrics that they believe are very good metrics to actually measure how well your organization is actually doing your DevOps in that sense. So first and foremost, deployment frequency. Second, lead time for changes. Third, time to restore service and fourth, change failure rate. So I understand that this slide has too many words and I personally don't like having too many words but I just want to put it there so that say for example, when you bring it back to your organization, you can kind of use this matrix to actually see how far along your DevOps journey you are. But part of this DevOps, this Dora research which is approximately like 80 pages, I kind of read through a few pages of it is that what they found was that high performance tend to have these four kind of characteristics, right? So first and foremost, they deploy multiple times more. So some examples are like companies like Amazon, companies like Google, they actually deploy like up to maybe 208 times more. I think I read an article somewhere where they said like Amazon basically comes up with a new version of their website every 10 minutes or so and they deploy it very, very frequently. They have faster lead times to commit. So from committing of your code to actually deploying it, it's a lot faster in organizations that adopted DevOps well. Time to recover from incidents. So from the point of creating an incident to recovering from it, whether it's an availability issue or is it a bug or a security issue, they are a lot faster because of the way that they deploy and they fix issue. There are also seven times lower in terms of change failure rate. So change failure rate in the way of like when they deploy code, how does it actually translate to a CI job failing or not being able to deploy to production properly? Organizations generally that perform better are able to actually hit these four matrix. And another article that actually kind of picked up on was actually a company in the US called Capital One. So Capital One actually believes in this concept really strongly. And even though Capital One's one of the biggest, one of the really big companies, I think it's a Forbes 500 company, they really consider themselves a star and they actually deploy code really frequently on a day to day basis. So I have all the links available. You can kind of take a look and read the articles accordingly. So these are just kind of like overarching strategies or in a way what Google and Dora kind of came about together to come up with this metric or rubric for you to actually measure your DevOps lifecycle. But how do you actually measure these metrics in your environment? So Google came up with a project and this is called the four keys project. So you can actually go to the source here and you can actually take a look at the source code for all of these things. It's more like a documentation available. So how do you actually measure some of these things like lead time to change, change failure rate, deployment frequency and time to restore service? So first and foremost, this project supports GitLab events and GitHub events if you're a GitHub user, basically pulls in all of these things by the extensible API that I was talking about earlier and able to chart all of these things across time for the long-term. Just a caveat for you to know is that when you deploy this project, the idea behind it is that you do have to install a couple of things, as I mentioned at the corner here. There's the requirements of having the technology stack of using Data Studio, PubSat, Bitquery and a bit of like, for you to kind of like massage your data, you kind of need to write a bit of Python code available. All of these things are available on the project. You can kind of see that over here. And this basically only runs on Google because it's a, I mean, it's led by Google, right? So if you want to, if you're using on AWS or using in a different environment, you might have to translate them accordingly. So GitLab has kind of taken a leaf out of that and tried to do something similar and we are trying to adopt some of the industry best practices. And what we have came out so far is really just one out of all of it. So it is something that we across the year, I mean, this calendar year within 2021, we are trying to achieve all four different metrics available, but what we have available right now is actually we have achieved one of the metrics, which is deployment frequency. So from a project level, we are able to actually see across the timeframe, how often you are deploying and from a group level, how many deployments are there happening? So because I earlier, I did see like not a lot of people are using GitLab currently. So difference between projects and groups is that it's just kind of a logical grouping of different projects. So you might have a project that's written in Ruby and another project that's written in like Java, but because of like that multi architectural thing, they might be interacting with each other. So that gave rise to the idea of like projects and groups and how you group them together instead of the other alternative like Mono repose. Yeah, so there's the link over here. So if you can see that, I put it at the bottom because I know if this is going to be sent out as a PDF, you might not be able to access it, but you can track the progress or how GitLab is trying to achieve some of these things. I think we should have most of it, if not all of it for like a first version within this year. And then we will definitely try and improve on having more customizability such as our value stream management analytics kind of dashboard across the next year also. Another thing is that for lead time to change, I think one of a kind of a way to measure this is also for in the group and projects insights. So over here, you can have actual dashboards available where you can see like your, how many issues are there per month and how many issues are you actually resolving across the board. These are all customizable. There is like the XML in the back end where you can actually customize and choose and create your own dashboards available. And I'll show you a little bit later on how that looks like. All right, so that is pretty much it. I just wanted to kind of like put it out there. It's like, it's more like a high level and this is what GitLab is trying to align ourselves with in terms of like what industry is looking at. But I just wanna show you maybe a little bit on like how it looks like in GitLab and give you a flavor so you can appreciate it a little bit more on that front. So first and foremost, let me look at value stream. So from a value stream standpoint, this is from GitLab.org. So this is our actual platform and our website. So over here, you get to see like from an issue to plan, to code, to test and review. These are all the different stages and what the tasks are underneath a lot of these things. We break down a little bit more as well as to show you like within each of this type of tasks, what are they doing at this point? So with the labels that we have in our organization, like accepting merge requests, whether these are just basically documentation, quality checks. Let me just zoom in a bit because it might be a bit small quality checks or you're doing certain tree arch reports so and so forth. All of these things are labeled and in a way to help you see whether you're getting your value quick enough. One of the ways you can read this is also like, are we clearing a lot of more tasks each month also or each day? So this kind of helps you to get a proxy in terms of like measuring the productivity of your team as well. So the other thing that I have, which I mentioned earlier just now, it's also your roadmaps. So roadmaps can be found on the epics in the roadmap column. And what you can see here is that I did put a few filters. I think the filters are really useful because right now I'm using GitLab.org which has thousands of epics which would probably crash my browser. So having proper labels and checking certain things would help you to actually see some of your epics or track your progress of a certain task across time a bit better. So over here, you can see that the label that I'm looking at is advanced. So personally, I've been helping out with the product team or like the developers in terms of like the elastic search integrations with GitLab at the back end. And these are basically some of the things or tasks that we have been working on across time. So over here, you can see how we broken it down like some of the tasks that we have like first search ranking, so on and so forth and how we have progressed about it. So over here, you can see like over here we have 50% of it done out of two tasks underneath and you can actually rank some of these tasks at level of importance. And this helps you to kind of track in terms of time how your tasks progressing across time. At the same time, over here at the top you can actually see these lines and these lines actually coincide with milestones. So for GitLab, we see it as like we coincide with a product release milestone. So every time we have a product release what are the epics or what are the issues that we have fixed? If we have fixed them, we then push it into release by that milestone release at the same time. So in line with that, you can kind of click and do it as well. So for example, if I were to look at something that was we are in 13.10 right now that was just released yesterday if I'm not wrong or two days ago, you can kind of see a little bit more into what this looks like. And especially for teams that are more involved in the idea of like your burn down charts or trying to measure, especially from a gel methodology, you can kind of see like how many tasks are being completed compared to the tasks that are being raised at the same time, right? So again, a proxy for how you can see your productivity of your team and how you in a way get to value a little bit quicker. Some of the dashboards available here, I don't have actual data because I only have a test environment here but some of the amount of deployment. So this is in line with like your Dora form metrics that you can actually see. Insights over here, as I mentioned, kind of a proxy on how fast or how many issues you are fixing a month. So over here, you can see like ish bugs that are created per month by priority. So you can rank them accordingly and by severity. You can have multiple different ones as well. And these are all customisable via the XML tool that you can have in the backend of GitLab. And you can have all of these reporting dashboards to teams that need to know, right? So at the backend, you can also have a lot of these things such as, for example, I'm only looking at availability issues. So having the ability to actually customize on this dashboard with the appropriate filters, that's really useful from what we've been hearing from a lot of our customers. So yeah, something like releases, again with the Dora form metrics, we can see the releases over time with the project, how many percent of them are actually releasing. Again, this is very, very initial. We are gonna flash it out with a lot more features available, but this is what we have now in terms of like supporting some of the Dora form metrics as well. Right, so I think with that, it kind of is everything I needed to show today. It is really kind of a very high level overview at the beginning right now. The next few webinars that we're gonna have, it's gonna be a little bit more in depth into specific topics such as like, into different stages such as your create stage or in the CI stage or your security stage. But this is kind of the first webinar for the year if I'm not wrong. And then we will go from there. So thanks everyone. Awesome, thanks for that Jonathan. Thanks for the very insightful presentation. We don't have any questions that came through the Q&A. So I know everyone's time is quite precious. So we'll probably end it there. Once again, thank you to everyone for tuning in today. Hope you found it very valuable. A reminder that the presentation will be shared with you via email in the coming days. They'll give you access to all the different information that Jon had provided. So yeah, so we have lots of virtual events coming up in the next couple of months. Things like workshops and our flagship APAC GitLab Connect event where we'll bring together a range of speakers to share their knowledge and all things DevOps. So keep an eye out on an email information, invitation for that. Again, thank you everyone. See you next time. Thanks everyone. Just had a question from Samuel come through mentioning events. Yes, we'll shoot through an email to you Samuel for any upcoming events. And we also have a events calendar. I will share with you the link to that now. Perfect. Thank you everyone. See you next time.