 Welcome to the first part in our series on CI CD. I'm Suri and I work on the content team here at GitLab. We're thrilled you're joining us as we talk DevOps and drawbacks. If you have questions during the presentation, please use the Q&A function at the bottom of your screen. We'll also dedicate some time to answer your questions at the end of the presentation. If you have any technical difficulties, please use the chat function and I will do my best to help you. Today, Victor, one of our solutions architects will present while John Jeremiah, a product marketing manager, will answer your questions. You can see here that we have quite a few interesting topics to cover so I won't keep you waiting any longer. Over to you, Victor. Suri, thank you very much and hello everyone. My name is Victor Hernandez. Suri mentioned I am a solutions architect at GitLab. I'm part of a customer success team. Briefly about me for just a moment, like all of you, I have been in software development for some time, in my case, 20 years. I have worked across a number of organizations doing software quality assurance testing, project management, and even agile coaching. In my immediately previous role, I helped teams and organizations with solutions for agile portfolio and project management. And lastly, for the past now 11 months, I've been enjoying my time at GitLab as an advocate for DevOps solutions. As for our conversation today, this is the first webcast in a four-part series. Today, we will be focused on the topics that you see on the screen. Over arching the conversation today is the general theme of broken DevOps. What we want you to get out of this webcast is an understanding or better yet a framing of the issues. What makes it broken? And the ultimate goal is to provide you with solutions to making your implementation of DevOps practices successful. So to that end, we're gonna be discussing, first of all, why DevOps? The challenges in software delivery. What is it? What is this bus worth? Where is it today? What have been the promises, the goals of doing DevOps, and what is the reality? And this will not be completed. We do not touch on specifically what can be made better. And you may know this already, culture, tools, visibility. Let's get started. Firstly, it is impossible or rather irresponsible to leave DevOps out of any conversation that involves best practices for efficient software delivery. Creating and placing great software in the hands of users and customers is not accomplished by using a specific set of tools, a single process or a team with a great disposition. All of those are great things, but focusing only on a single one of these elements is merely sub-optimizing an aspect of the whole. Drawbacks as stated in our title slide refers to the complexities which must be overcome to achieve our objective. Once again, that successful delivery of value through superb working software. I want to start us out by relating a horror story, a DevOps horror story. And you may have seen this. You may have read the account, perhaps even in the context of broken DevOps. This particular article at some point calls it 45 minutes of hell. So briefly, what happened? On August 1st, 2012, at the opening of the stock market, the night capital group begins processing orders on behalf of their customers for a new trading program. But right away, there is a problem. Ironiously, the firm's computer systems begin to rapidly buy and sell millions of shares in over a hundred different stocks. I said, ironically, those trades in error pushed the value of many stocks up and the company had to sell the overvalued shares back into the market at a lower price the next day. At a big loss for them. Once this all was said and done, those 45 minutes of hell, the night capital group lost $440 million and they ultimately blamed this on a computer glitch. And up until that week, the night capital group had been one of the biggest beneficiaries of the evolution of the market, particularly in terms of technology. They were helping their clients trade in and out of stocks at very high speeds. Sadly, the company did not recover in its original form and they were subsequently acquired and merged with other holding companies. What really happened, it was a computer glitch, as they said. In his blog, two years after the fact, DOG7, who is or was the ALM product strategist for Visual Studio, describes what happened in detail and he calls it a DevOps cautionary tale. So briefly, in preparation for launching the new program, night capital updated their automated, high speed, algorithmic router that sent orders into the market for execution. The update was intended to replace all unused code, functionality that had not been used for eight plus years. That updated code though, repurposed an old flag used to activate the old functionality. So we have an update with new code, but we still have old code in place that was activated by an old flag that was in this case used again, repurposed. At the time, the code was tested and worked correctly and reliably. And when the market opened, seven other servers had the correct application deployment and began processing the orders correctly. But orders that were sent to an eight server, triggered that old flag, the repurposed flag and this brought back, if you will, from the dead, the old piece of code. After the fact, the SEC filing did their analysis under findings and let me quote what they said, during the deployment of the new code, one of night capital's technicians did not copy the new code to one of the eight servers. So we had seven servers with the right code one without it. Night capital did not have a second technician review this deployment and no one at night capital realized that the old code had not been removed from the eight server, nor the new code added. Night capital had no written procedures that required such a review. So there you have it. The DevOps aspect of this particular unfortunate error and mistakes, the lessons learned and you likely already thought about this. It is not enough to build great software and to test it. Development and operation teams also need to ensure that it is delivered to the market correctly. In the case of night capital, there was a lack of process in place. There were practices inherently prone to error. Think about this, anytime that a deployment process relies on humans reading or following instructions, an organization is exposing itself to risk. Deployments to all extents possible and reasonable need to be automated and repeatable and free from this potential human error. The principles of continuous delivery apply in this case, CI-CD. Releasing software should be a repeatable reliable process and we should automate as much as it is reasonable. This brings us to the following point. Software is used in every industry and competitiveness hinges upon an organization's ability to develop software faster. The business speed equals its software development speed or should equal the software development speed. These faster cycles require continuous testing, require continuous validation. To keep up with this pace of innovation, the development cycle needs to be efficient and ergo, that software development is key to staying competitive. The crux for efficient software delivery then is adopting or enabling DevOps. At this point, likely you have read books, maybe you have written books or blogs and articles. You likely are also probably using practices and integrated solutions for your own DevOps environments and initiatives. So to level set, let's consider two related definitions of DevOps. The first one, going back to Wikipedia for a general high level definition. DevOps is a software engineering culture and practice that aims at unifying software development and software operations, DevOps. The movement strongly advocates automation, monitoring at all steps of the software construction. This includes integration, testing, releasing to deployment and also infrastructure management. This is key. DevOps aims at shorter development cycles, increased deployment frequency and more dependable releases. And what I like the most about this definition is in close alignment with the business objectives. Going a little bit further, let's consider Gene Kim. I'm not rather sure that you also know who he is. He's an award-winning CTO. He's a researcher and author and by many he's considered the forerunner of the DevOps movement. Gene adds to that definition that DevOps should be defined by outcomes. Once again, alignment to business objectives. It is those sets of cultural norms of technology practices that enable the fast flow of plan work from development through test operations while preserving world-class reliability, operation and security. It is not about what you do, but what the outcomes are. So many things we associate with DevOps such as communication and culture fit underneath this very broad umbrella of beliefs and practices. So it is about the right type of practices, the right type of processes and its culture. And all of this adds to your outcomes aligned with the business objectives. This is the realization of that definition. An infinite loop of increased and continuous collaboration, increased efficiency, faster cycle time. If you will, this is a silver bullet. In theory, implementing DevOps or the result of implementing DevOps should be an endless cycle with significant overlaps with successful deliveries. To be fair, the term silver bullet here does a bit of a disservice to DevOps. Many organizations have created successful integrated ecosystems where they have automated enough of their processes to deliver reliably and frequently. And often you may think about some of those organizations, for example, the Netflix of the world. These unfortunately are not the norm, which brings us to that other bullet point from our introduction. What is the reality of DevOps? We've talked about the definition and the promises. What is that reality of it today? Across the industry, we have a solid understanding and no shortage of resources, frameworks and tool choices to implement DevOps. Many teams today are practicing at the very least a form of DevOps, but they may not be optimizing the entire capability and functionality of the model. And as with anything, there is always room for improvement and in many cases, transformation. So to the reality of DevOps, let's speak about a few of these functions that unfortunately are still present with some organizations today. Some of you may be familiar with them as well. Marvin Lee is a software developer. I follow him on Medium. And I like this article that he penned a couple of years ago. It provides insight into several demanding but necessary constructs and activities that are fundamental for efficient deployment of software. One of the quotes that I like from this article, deploying code is paramount for a developer because it's how we bring value to our products and services. As your team and infrastructure grows, shipping code can become either a healthy challenge or an absolute nightmare depending on the choices you make. Marvin goes on to say, in a former life, I lived in software deployment hell. I heard engineers cry in agony as they released code over and over, not knowing if their bail would succeed or if it would crash and burn. Let's consider what he says are those nine circles of deployment hell. And these are familiar scenarios, each of these from zero to eight, starting at number zero, no infrastructure automation. Deploying or delivering an application requires installation and configuration of operating systems, web servers, programs, libraries to run the applications, databases for web applications. You have load balancers and other appliances in place as well. Without infrastructure automation, every single deployment may be lengthy and prone to error. Waiting too long to integrate, number one, changing software introduces risk. Really big changes introduce a lot of risk. The longer you wait for that integration, the bigger the risk. Number two says no staging environment. A feature tested on a developer's local environment may work well, but there are no guarantees of how it will behave in production. Back to my QAN testing days, it is never a good answer to say this works in my system because we're not shipping my system. A code that goes from a development environment to production is like drawing with your eyes closed. Maybe you know the way to get somewhere by memory where you are completely blind to anneal for scenes. No performance testing at number three. Low tests are a critical part of performance testing for any resource intensive application and with lots of users. If you're not measuring performance, this is bringing in serious risk. Imagine an organization that is producing web applications but that doesn't know or can't meet the expected traffic and their service level agreements. This would be crushing to their business. At number four, we have manual deployments. For any of these lengthy checklists of manual steps to deploy code, often involve logging into the production machines, running your deployment scripts, editing configuration files, configuring hardware, running data migrations. This is dangerous. Once again, our horror story, humans make mistakes. Deployment mistakes can be severe, that nightmare scenario. If an organization is deploying often and they're using a manual deployment approach and let's say that it takes 30 minutes to run the scripts and go through that checklist, those deployments could consume the bulk of anyone's day. Number five is close to my past experience, manual testing. Particularly when manual testing is the only testing that we do and we do it after the software is written, it's gonna take time. And that time not only is it gonna cost additional delays but when bugs are found or the software quality is not up to standards, we are simply adding more time to that delivery and any rework, any addressing of bugs is gonna prevent us from getting software into the hands of our users and customers at the right time. No monitoring at number six. I like this quote also from Marvin. Deployment without monitoring is like dropping your code into a dark abyss, not knowing what will happen to it. If we're not monitoring those deployments, how would we know if the applications are less than performance? What if a server goes down in the environment? How would we know about it? That is also key or one of the key aspects of a successful environment. This is almost hard to believe as well but number seven, no version control. Hard to believe that an organization may not have that software version control but it is quoted in the article, so it happens. This is a cornerstone of deployment, starting with your version control and this is where continuous integration starts, CI. Imagine that someone's making a change directly into a master branch or they're logging the SSH into a server and they're changing something on the fly. We have no means of knowing quickly why that change was introduced, how it was introduced. And number eight, really the ninth circle of deployment hell, poor communication, bad communication, as say with the case of night capital. There wasn't someone to communicate but even then there was nothing to communicate apparently. We had already experienced drawbacks and challenges from not having any of the other aspects in place. And I mentioned this earlier, unfortunately some of these practices still linger and these are affecting that promise and goal of successful DevOps. Let's talk about numbers and hard data. Take that number from the money aspect on the left. This represents 3.8 billion dollars. The world's largest market research store, research and markets ran studies with information professionals and they produced a DevOps market report covering the years 2017 through 2023. And this report provides extrapolated figures of money that will be spent in DevOps and the figure for 2018 that was based on forecasting and compound annual growth rates that gives us an 18% of the total which for 2018 was 3.8 billion dollars. So 3.8 billion dollars will be spent on DevOps tools in 2018. In terms of effort, that middle figure, using calculation estimates of distribution of effort by phase for the software development lifecycle, it is possible to estimate the number of person days of effort required for the total for a software development project. With that in mind, more than 50% of project DevOps time is wasted on coordination and tasks that have not been automated. And that's for satisfaction. According to a Garner survey of 400 organizations, 50% of respondents blamed people and culture issues for holding DevOps back. And additionally, 37% said they could not find existing processes that actually work for DevOps. This is relevant because only 8% reported that there were technological barriers or roadblocks for that satisfaction. So cumulatively, 87% of the satisfaction. Very short at a very high level, despite 3.8 billion dollars having been spent on DevOps software or that will be spent on DevOps software for 2018. More than half of the time will be spent on DevOps. It's gonna be wasted unfortunately on logistics and repeatable tasks. And in addition, almost 90% of the organizations are still disappointed with the results that they're getting to date. In that previous slide, we talked to investment, we talked to effort, we talked to results. Let's shift to causality. With a high percentage of the satisfaction, what are some of the reasons why we have in higher rates of realization? And I'm pointing out three, maybe the three big ones. Even now, when technology companies continue to innovate quickly, there's still happening some of them. For example, on the far left, teams are still culturally siloed. Siloes between teams and their tools makes it challenging to understand the big picture. Instead, individual sets of information lie with those different teams and their respective tools. And that lack of transparency across the DevOps organization slows down that pace of creation. Now due to barriers between these teams, the handoffs are inefficient. Individual silos means that teams may rely on manual, maybe semi-automated or maybe fully automated handoffs, but even when it's fully automated, often one team cannot start their work until the previous teams finish their work. And different permissions and security policies across these different teams, these different silo teams can lead to a controlled environment where it is difficult to establish trust. These challenges are not new. Coming from the world of agile and likely also you know the agile best practices, those had their inception in finding better ways to deliver software. And they're still present with us. And he would come at last to the root of a problem. It all boils down to culture, tools and visibility. It really is all about the culture, the definitions from Wikipedia, the definition from Gene Kim, likely your experiences all lead us down this path. As many other aspects we may consider, culture is still the most important aspect for better and worse. Above all, DevOps is a cultural philosophy. It requires patience, it requires hard work, it requires understanding of people, requires support from the business, getting to those business outcomes or those outcomes aligning with the business objectives. DevOps is about collaboration, about coming together as a team to achieve that goal. Your operations teams must be aligned and in constant communication with the development teams. Everyone is either all in or the objectives will be much more difficult to accomplish. Tools, tools, tools and more tools. Within a single organization, there are usually multiple tool sets and often to accomplish the same purpose. With this multitude of systems, whether they're integrated or not, information is still fragmented throughout that ecosystem. And teams must pull together all that knowledge when it comes to audits, when it comes to governance and when it comes to compliance. And this leads to obvious challenges in visibility. A dysfunctional culture and a fragmented tool ecosystem fuel a lack of visibility. If there is a common purpose in software delivery, without a homogeneous approach to that delivery, this drawback, this lack of visibility leads to further difficulties. For example, guesswork, unpredictability, blame, security as an afterthought, waiting for permission, approvals, handoffs, not knowing where the information is at any given point. So what to do? We touch on a number of topics and issues that weigh heavily on a successful implementation of DevOps practices. We focused on aspects that are really difficult to discuss. For example, we started with that DevOps horror story with disastrous consequences for night capital. We zeroed in on the general definition and the commonly accepted expectations of what a good DevOps organization should produce. Silver bullets, and we talked about those, are not entirely unrealistic in our space, but much money and effort has been spent in this endeavor. And unfortunately, with high rates of dissatisfaction still prevalent. And culture, your fragmented tool ecosystems and visibility are challenges yet to be solved by many. We set out to briefly frame out some of the issues. They're not easy to solve, but they're also not also mountable. It all comes down to three basic building blocks. People, process, and tools. For people, it's a culture of collaboration between dev and operation teams. For processes, they should be clearly defined. They should be reliable, repeatable, implemented through technology. On the tool side, tools that help us automate are repeatable processes that help us to configure, test, deploy, that help us to create environments for our deployments as well. These are what I'm calling here, that silver bullet for successful DevOps, for successful agile practices. We have framed the problem. We've come to a conclusion that is seemingly very simple but very complex to implement. Now, how can we help? GitLab can provide tremendous value across the spectrum. And here's where I'm gonna hopefully wet your appetite for more. We have more webcasts in this series and on May 9th, we have the next webcast that continues to explore and expand upon what we've seen today to really ultimately solve that collaboration conundrum, if you will, to make DevOps, that DevOps goal a reality. Hopefully this was a good introduction for you and this was helpful and brought back, really brought to mind many of the challenges that you, that us are facing because we all have that same common goal of making our software delivery of value successful. So I thank you for your time and we live now this time open for questions or follow-ups. If we can talk about any of these topics in more detail, we're happy to do that. Thank you so much, Victor. We'd like to take some time now to answer any questions you have about DevOps or the challenges that teams face when adopting a DevOps model. So we see one of the questions that are coming in. The question is, what do you think are the biggest cultural barriers to DevOps success? So maybe let me answer that at a very high level. In terms of culture, and it's easy to say this and it sounds like the easy way out to answer this way. It starts with mindset. Say as a developer, ask yourself, what impact does this one line change have in production? Because it's all about the outcomes going back to the definition of Gene Kim. It also goes back to our desire to do better and to do better faster. And better faster means with quality. It means with having the right controls in place. So from a cultural perspective, it starts with mindset. It starts with that goal, with that unified approach to understanding that we want that deliverable to be successful. And say for forgetting started, once we have that cultural barrier, if not overcome at least in process, start simple, start small enough. Say start automating builds and some of your basic tests. Hopefully that was useful for that question. Thank you, Victor. We have a question from Mohamed who asks, how can an organization hire for DevOps? Thank you, Mohamed. And certainly great question as well. I'm thinking about the type of people that we hire here at GitLab, because ultimately at GitLab, that is our one common objective, that outcome. We're trying to provide solutions for successful DevOps or successful delivery of software. On the mindset, we make sure that we hire people that come from a background where they have shown that they like working with transparency, working with other teams. And that process involves many different individuals, say from GitLab perspective, across different functional teams. So we can get a good idea of where their mind is. They may have all the technical requirements, all the technology requirements in place. We'll make sure that they play well with others because they will be required to play well with others. And that's where the culture is so important. So it's not only the skill set that is very important, but making sure that you get a good notion of that cultural mindset for that individual. Great. And now we have a question from Scott, who asks, do you have any suggestions for optimizing or right sizing DevOps for small teams? For example, two to six developers. Another excellent question. And it's interesting that it comes up, or maybe it's not so priced in that it comes up right now, once again, with that agile background and with that coming from that world where we do that type of right sizing, your teams are gonna be at their best when they are between five and seven overall high level. I would say on the DevOps side, it's very similar because it's all about agility. And once you start having very large teams, you start getting, or you start crossing those cultural boundaries of how well the team communicates. Two to six, five to seven still seems like the right approach. I'm not making recommendations here, but personally, and what I've seen at Gelab, that's also the model that works pretty well. And hopefully that was a useful scotch. We have a question from Martin, who asks, for small companies, is it better to build the DevOps solutions inside, like GitLab CI, or is it better to outsource the solution to focus on the product, like Hiroko? Another great question, and I don't know that I have an immediate answer. What I see most often, particularly at GitLab is organizations doing that right-sizing of teams and implementations within the organization, even if the organization is highly distributed. And at least in our case, and this is thinking not only about culture, we're thinking about a toolset, it's having a toolset that enables all those different teams whether they're business-type teams or DevOps operations-type teams. So that tool also serves as a unified force across different locales, if you will, with both external and internal people. Hopefully I didn't go outside of the context of that question, but let me know. I'm pretty sure that it would work even outside of that realm, but at least at GitLab we're making everything, or at least at GitLab the experience is that everything is working very well within the organization. Great, and now we have a question from Gee Chow. I hope that I pronounced your name correctly. If I didn't, please forgive me. He asks, are there any organizations that have implemented DevOps successfully and to what extent? I would say absolutely. And at least in the service, I'm thinking, and I mentioned this briefly, I'm thinking about the Netflix or maybe the Facebook and all these software companies that we know are delivering quickly, not only a rapid phase, but also when they make a mistake, they immediately roll back and deploy again. So I would say absolutely. And thankfully I worked with some organizations here at GitLab that are doing just that. I don't think there's a perfect, going back to that silver bullet analogy, a perfect organization that is doing everything right, but I think that the ones that are doing it right are those that are enabling or adapting to change quickly. Going back to one of our previous questions, David asks, speaking of five to seven developers, how does GitLab support agile teams? Which I see was answered in the chat box. Okay, so our next question is, when we talk about culture, how much of DevOps do you believe is about efficient human communication? Personally, I would say that all of it is, all of it is, even if you have systems that enable automation of processes, that enable automation of testing, of configuration, of deployment, none of those systems get to be in place unless you have that communication upfront. And that communication is not simply between say, within the operations team, how do we deploy to our different environments, but it starts with the development team. How can I reliably and how can I efficiently provide you with my code so that you can deploy to those different environments? And let's take it one step further to the left. From the business side, how can I be on the same cadence as my development teams to really inform them of say requirements of user stories of issues that need to be addressed in the code and ultimately how, from a business perspective, can I see all that change flow from the time that I put that in to the time that it is delivered? So I would say that culture and communication go across all those different teams and that even using the best and most efficient tools that communication is paramount that is the first aspect to be considered. Thank you so much, Victor. We have one question from Andy who asks, how do we get people on board with the new tool when they use an existing one and like it? And do you get everyone to ultimately become tool agnostic and think more about the outcomes? Ah, well, now we get more into the tool discussion and of course here, the campus all over the place, you know, are we tool agnostic or do we center on a single tool? I don't think there's a right answer to either but I think that what must be considered is what is going to enable all of us to not only have that successful business outcome but certainly communicate effectively and collaborate with each other effectively. All of us have preferences for tools and many times I think that that preference prevents us from going outside that comfort level which is also where that spirit of Kaizen of Aline mindset, I'm going to continue to inspect and adapt and measure and transform where needed. No right answer there. I think both approaches can enable teams and organizations well connected efficient tools or a single tool set as long as you're getting the right business outcome and gender through the right level of communication and collaboration. Hey Victor, I wanted to just jump on that because I think this is a real problem that people wrestle with is how do you get people to change and any change you make to the way people work whether it's the tool or the process or anything you change is hard. And I think one of the keys secrets to success is to build enough training and enablement to teach people how to work in the new tool. So when things are different in a new tool so it's not just the benefits but teach people how to be successful getting their job done. So you have to understand what their job is or what they think their job is and then teach them how to do the tasks they used to do in the new way. I think that's one of the key bridges to making people move from what they're comfortable with to a new way of working. Thank you John, I like that a lot, thank you. And we have a question from Joseph who asks what would you suggest as an optimized process that allows teams to run DevOps? Currently our governance is holding us back with multiple checks and balances in a waterfall way causing developers to be frustrated when trying to work agile. Which is also very similar to the challenges that we had maybe some years ago when first trying to implement agile practices or to evangelize agile practices how do we satisfy those requirements whether it's a waterfall world or an agile world? Thinking maybe in terms of solutions I would say that it's essential for an organization to improve their cycle time whether waterfall or agile to deliver faster. And why is that? Because that allows them to get feedback sooner, quicker get some risk out of the way, get the documentation in place, get the audit logs, get the governance requirements satisfied as early as possible. Thinking more on the tools side, a system that is going to help enable that type of practice, that type of governance, that type of audit it should provide you with information in a single source of truth. So that compliance teams can effectively audit those standards and make sure that through that automation that critical testing is taking place and once again that you can get to those goals faster it's not going to be an easy transition and like I said, the overall answer with people, process and tools is entirely too simple but it's quite complex to get there. But if you can get started with some of those practices for improving your cycle times for delivering and testing faster and sooner I think you're going to have a lot more firepower and evidence that you can meet those standards of governance. Hey Victor, can I add to this? Because this is another challenge and I've done a lot of work in the past with a writer and an author named Gary Groover and Gary led the implementation of continuous delivery and at Macy's.com and he was a VP in leading that transformation. Gary's written a couple of books who started in scaling enterprise DevOps and he talks a lot about this and one of the things he describes is how he was able to increase his compliance and his audit compliance of his team because he adopted continuous delivery. And the way he did it was in his pipeline he built in the automated checks and the automated updates and reports that they had to do in order to document compliance. So he worked with the government with the auditors and with the controls team people who define defining the general control so that his pipeline automatically did the steps in order to demonstrate compliance. And when his team got audited later as they went through audits it got to a place where the auditors had nothing you had almost nothing to do because he was at 100% so he actually part of it's about working with the auditors but it's also about embracing how the automation in your pipeline can ensure compliance, right? And so I saw the same thing with HPIT when they did something similar where they implemented a standard change record as a way to document and this change record was created for every change that went through the pipeline. So rather than going to a change advisory board in the traditional ITIL processes they decided to say, look our process will document who approved the change how thoroughly it was tested all of this got created into what was called a change record and then that was the evidence that they used to demonstrate compliance with release management processes and standards and therefore anything that went through what they called their DevOps pipeline was stayed out of or didn't have to go through the more traditional processes for how they were doing manual releases. So I think there's ways of doing it but you have to really think about how does DevOps enable you to consistently document what's happening and to automate those steps such that you're 100% sure that you're ready to go along with what Victor talked about is having clear transparent visibility as to what's happening. Thank you, John. We have another question here. How do you make your communication between teams at the right level? That is to say, how do you make the correct assumptions about people's level of knowledge without having to over or under explain? And another question very much on the lines of culture. For me a good model to follow and this was not entirely new or novel but when I first joined GitLab GitLab has what I think it's a very efficient way to communicate with others and it's part of our handbook. If you go to a website and just look at the handbook it's visible there but it's all communicating with our team members. We use an asynchronous type of communication standard here across the organization. Standard is maybe too strict of a word but we try to make that feedback relevant. We try to make that feedback about the expected outcome and not the person. So thinking about what the question said regarding maybe speaking or communicating with different people with different levels of experience of expertise. It's all about how we can work better as a team and that feedback should reflect that that it's about the outcome is not about the person and by saying all these things I'm thinking very subjectively. So Suri if that helps I would say that for that question I would recommend looking at our handbook and we can send a link to that. That specific aspect of how we communicate internally which I believe is very effective. But also wanna make sure that I address that question. Thank you so much Victor. All right it looks like we have no more questions. So thank you all so much for joining us. We hope you learned a little bit more about DevOps. If you'd like to learn more please visit about.gitlab.com and we hope you'll join us for the second part of our series in which we'll explore ways to make your DevOps dream a reality. Thank you again for joining us. Suri, John and everyone in today's audience thank you very much for your attendance. Thank you for the questions. Hope this was useful and helpful and I will look forward to seeing you again in the next webcast. Thank you everyone, bye. Thanks, have a great day.