 Okay, so let's get started. What I'm going to do today is talk to you about DevOps and in the open and the inner sourcing world. Share with you what we do in Microsoft, a few of our learnings, best practices and just share that so that we can hear from you as well. So welcome everyone again. This is Divya Vaishnavi. I'm a Program Manager in Azure DevOps, and I would love to hear from you feedback on this session, feedback and questions on how you do DevOps in your enterprise startup. So reach me out at Divya Vaishnavi on my Twitter handle or on LinkedIn. So let's get started. Every company today is becoming a software company. If you think of it and think of food, travel, entertainment, shopping, hotel, whatever you, all of those are now becoming software companies. Digital transformation and app modernization is one of the key initiatives at most executive levels, and maybe you're working on one of them already. The hiring of software engineers also is growing 11 percent more in the non-tech industry than in the tech industry. And in all mix of all of this, DevOps becomes super important. DevOps allows you to accelerate delivery while still delivering reliable products and services. It's about bringing people together through shared common goals, increased collaboration, and a focus on improvement. Technology plays a key role by enabling teams to collaborate more, enhance productivity, facilitate experimentation, a key component of DevOps, and automate their process from development through to delivery and operations. So it's all about delivering faster value to your customers with increased efficiency and hearing back from the customers the feedback so that developers can continuously improve the product. So the end result is a better product delivered faster to happier customers. We in Azure have a comprehensive DevOps Foundation, whether it's Azure Pipelines for your continuous integration and continuous delivery needs, boards for your work item or your work management, Kubernetes, Azure Monitor, Artifacts, you name it and we have it. We in Developer Services, the team that I'm part of, our key goal is to help teams to collaborate productively, ship frequently, and learn continuously on Azure. One of our other key goals is the one engineering system that is helping every engineer in Microsoft to deliver with high productivity. This is something that's a key on the radar for Satya Nadeela as well. So what we have is 107,000 engineers in Microsoft using Azure DevOps to deliver their features, their functionality. If we do a back of the envelope calculation, if you're able to save a second per day in the life of these 107,000 engineers, it's about getting 3.7 more people to Microsoft. If we save a minute and help with the productivity there, it's like 163 more people, and an hour adds up to almost 2.7 billion per year, which is a lot of money and thus, productivity is a key focus for DevOps in Microsoft as well. Now, going and sharing some numbers here, DevOps at Microsoft, what we have is a tool chain which is used by like I said, 107,000 internal users with 82,000 deployments per day, 442K pull request, and we contribute to 3.5K open-source repos, 12,000 folks in our teams, employees contribute to open-source. So open-source is a key in Microsoft. We at Microsoft love open-source, and with every passing year, you will see that we have done more and more in the open-source realm with 2019, culminating with GitHub being a part of Microsoft. So Microsoft continues to be the largest contributor to open-source projects on GitHub, and now obviously helps GitHub reach more customers and add more value add to the world as well. Most of you are aware of the benefits open-source brings in, how it enables the technology agility, access to community of like passionate developers, but in enterprises, many times it's not encouraged. So we'll talk a little bit about inner sourcing as well, given the concerns or in your proprietary organization and teams, how can you do inner sourcing as well? So inner sourcing at a high level is a mythology that applies all the lessons learned from the decades of open-source development, and bounded by the concerns of tech leads and developers working inside a proprietary organization or an enterprise. So it's a catalyst for DevOps transformation. It's helped allowed teams to promote transparency, reuse, and enable innovation. Whether it's open sourcing or inner sourcing, it promotes higher quality of code. Since transparent code and processes open every lineup to wider review, that's not practically possible in a smaller team. As a developer as well, you write better code because you know others are going to use it. We as developers today are very lucky. We get to and choose to build applications on top of existing landscape, existing code source, components whether from the open-source world or components from our sister or partner teams, so that we can spend our valuable time innovating rather than reinventing the wheel. Few of the best practices like I wanted to share for inner sourcing at Microsoft are like this, and it applies to both open sourcing as well as inner sourcing. So the first one is be inviting. So if you have your code base, be available for folks in your team, or if you're obviously contributing to open source GitHub is one of the great places to have that where the whole world 38 million developers use it. Having a good read me and contributing file, which gives the details of what the project is about, how to set it up, what contributions are you looking for? Like one of the things that we do is we maintain a work item query, which gives details of what is up for grabs or the opportunities for contribution. Having details of instructions and directions for contributors as well is really helpful. So once you've invited contributors, the next one is to reduce friction. Now, when you've shared your code in a way that encourages contributions, your code obviously gets better by new features coming in from other teams or enhancing that product which might be, say, a functionality which is needed only by that team. So making it easier for contributions, obviously reducing friction makes it more easier to get contributions. One of the key things there is not having special permissions, making your code approachable, readable, and buildable and testable. CI CD plays a key important role there. I'll demo some of the stuff in a while, but having a pipeline already set up just makes that build and test really easy. One of the key things is also like measuring how easy it is to launch the first build and test, and doing it in, say, under 20 minutes is a good ballpark or a baseline to look into. The next one is putting the right gates, making sure that you have the right experts in the team who do code reviews, as well as gating it with the PRs with a CI setup, with test setup, which makes sure, so if you have a CI setup for your PR, which makes sure every time a PR gets checked into your master or your main branch, there are a series of rigorous quality check, which makes sure that the quality of the code that is coming in is at the same bar. The next one is be open and responsive. Now that you have made your code available, you have contributors. Encourage that by measuring the time to first response. It helps understanding as well, and maybe setting up SLAs that you would want for how fast would you respond to that PR. Having a feedback system in place for potential contributors also helps so that they can provide commands, feedback, and rate their experience of contributing to your code base. Now we talked about all of that as a team, which is wanting contribution, how about being a considered contributor as well. So when you are contributing to somebody's code, some of the rules or the things to remember are, go read the documentation which is available in the project, in the repo before you ask questions. Provide high quality contributions, make sure your PRs have the right test, and respect the project code style and test requirements, and communicate early about intentions. If you remember, I talked about work item query, which mentions what's up for grabs or what are we looking for contribution one. Link to that or show your intention of picking up that task or user story or what have you. So these four practices is what we try and follow in Microsoft to help inner sourcing or teams contributing to another team. Now what I wanted to do was also share how these best practices define team performance and help drive a better product. As part of a hackathon project, a few of us in my team had done an analysis and I just wanted to share our details or our findings from that analysis. What we had done was we selected 12 parameters, mainly in the categories of collaboration, code, and popularity. So if I have to give some examples, it's like PR response time, issue response time, what's the PR inflow, outflow, how fast are you closing, how many are you closing, new contributors coming in the repo, new activity, open issues, folks, blah, blah. So 12 parameters that we used, again, category of collaboration, code, and popularity, and then we measured it across each team. What we then did next was map these 12 parameters in a two-dimensional space to see if we can get clusters of team with scores ranging in the high, medium, and low, and the team categorization was done based on these parameters. If you see here, what you'll see is there are three distinct clusters which got formed, high, medium, and low, and knowing which of these teams were, we were able to confirm our hypothesis that these, the right behaviors, help define the team performance and a better product. One of those green dots there is, say, VS code, and few other teams that we, like these, all of these analysis were done on open source repos which are owned by Microsoft. The next thing we did was like a further drill down into the PR-based matrix, again on the number of issues or response time, and what you'll find here, again, is the teams which are performing better. So the A team here is a better performing team, and the B team is the medium category, or the high and the medium category teams, that one team regulate the debt periodically, and the other continue to increase the debt, then take action or whatever go in the bug freeze, feature freeze zone, resolve issues, and then address the debt. Again, some of these characteristics help define the team performance. Now, let's go to the last section in this talk, which is the demo. So what I wanted to show was the four things that we talked about. How do you make your code more, or your repos more accessible? How do you find it? If you're looking to inner source, contributions, PRs, CI, CD. So I will switch to, I'm gonna use Azure DevOps, like the product that I had mentioned, and what we have here is the ability to search for code base or for repos across the whole organization. So what you see here is the organization for MS data, which has like your SQL, Cosmos, Azure Data Lake, Data Factory, and so what have you. And I can actually search for code base across all of these projects. So let's just look for say SQL parser. What you'll see here is it's giving me the details of SQL parser, which is available across the various projects. If I had to go and look at specifically say in the data lake or algorithms and data science, I can go there, filter it out to that, or any of the other ones that I am interested in. So if I go and look at SQL data catalog, I'll have the details of the SQL parser utility. I can either reuse it, so take a dependency on this or contribute back in terms of say adding new functionality to it. And adding a new functionality is as simple as making the change and creating, raising a PR against that file. So it helps having that open availability across the projects. The next one I wanted to use was few of our GitHub contributions and the well-known ones. So if I just take an example, say of Rosalind or VS Code, which is available on GitHub, each of these are set up with a CI CD pipeline. So if I take say Rosalind, what you'll see here is a matrix of pipelines which are set up to help test this platform, .NET compiler platform as well. So if I just take an example of the debug 86, what you'll see here is this is the pipeline which got triggered by this change, this commit coming in on the .NET Rosalind framework and it runs a bunch of tests. If I go here, what you'll see is there are 676,000 tests which have run for each PR. So here again, you will see there are multiple PRs that are coming in. This was a CI built, but there are these multiple PRs coming in as well. And each PR has this huge number of tests running to make sure that the quality is, the PR, new PR is not breaking any of the current changes and the new PR also has the required tests associated. So when I click on the PR, it'll take me back to the GitHub repo and it gives me the details of what has changed and whether the pipeline has passed or not. Only when that pipeline has passed, the PR is closed. The last one that I wanted to do was take you to VS Code which again is on GitHub has, does few of the, let me just go to GitHub and go to VS Code, not in this repository in all of GitHub. And they do a great job at what I had mentioned about opportunities up for grabs. The issues have those tags available, which you can use to understand what data or what is available that you can contribute to. So if you browse through that, you'll be able to see that feature requests and things like that. And again, it has a pipeline setup and every PR goes through this test. Every PR has a code reviewer and goes through a bunch of tests which help making sure that on various platform, whether it's Mac, Linux or Windows, the quality of the product continues to be, continues to be at the level that is required. So coming back to our key part, helping with these best practices of allowing inner sourcing, encouraging contributions and putting the right gates and balances, having your DevOps cycle or your products set up, specifically your CI CD, just helps make that whole process really smooth and really fast in the delivery to the customers. That's all I had. If you have any feedback, like I said, please reach out to me on my Twitter or LinkedIn handle. Do you have any questions? We don't see any questions. You hear me okay? I hear you okay. Perfect. Yeah, there's no questions at all. I think everybody wants- I don't know if that's a good thing or a bad thing. Well, so it's been the norm and I think everybody like ancient quarter just said good stuff. I think that everybody's like, uh, if I ask a question, how am I gonna put you in Q and A here? If I ask a question, then they may not think I'm smart or the content is really that good. Yeah, that's what's on Twitter earlier. Yeah, as ancient quarter said, it's all a good thing. Yeah, it was neat to see great, good talk. So yeah, it's awesome. Thank you so much. I mean it was- Thank you so much. It's amazing. So let me ask you this. If I am a developer out there, you know, maybe doing that net, you know, I could be doing anything. What is the value proposition for me to be using Azure DevOps? Can I use it for free? Oh, yes. So multiple value propositions for Azure DevOps. And the first one I wanna start off with is, it's applicable and available for any app, any technology, any framework, and I should also add any cloud. So it's not necessary you're just deploying to Azure, you're deploying to GCP, AWS, on-prem, it's the CI, CD tools allow you to do that. In terms of the key value props is, Azure Pipelines is the only tool available in the market which helps you build for Windows, Mac, and Linux. If you are, like, if you're doing the open source, if you're building open source product in GitHub, and let me just go there, we have an app to the Azure Pipelines app is available on GitHub, and it's free 10 parallel pipelines for any open source project. And if it's a private project, you still have like one free pipeline. And just like that is super helpful. In terms of, again, the technology that you spoke about, we have templates for Node.js, you name it and the pipeline support it. So in terms of, again, continuous integration, so there are tasks available in the market for, or in the product for all technologies possible. We support all test frameworks. So yes. Awesome. Actually, as you were answering that, we got a question from us, Babwa, who, or Washington, I don't know, WA, is asking Azure CI, CD free tier has limited build minutes. Is there a strategy to do one build a day? The free build minutes are limited. Oh, what's the next trigger? Sorry. There you go. Sorry, go ahead. You can actually buy more parallel jobs at $40 per month. So you can buy more parallel build time as well. Gotcha. Yeah, so that way, so if I have the free minutes and I pay an extra $40, or it gets translated to my currency, then all my pipelines will then use that new unlimited setting. Yes. Perfect, awesome. What about you, Jeremy, any questions? This sounds pretty cool. Put me on the spot. Yeah, I know I've used the Azure DevOps actually for a few of my own open source projects. Oh, that's awesome. Very straightforward to set up, fun to use, and it's unlimited for public repositories, so. That's great. So let me ask you this. You mentioned about, you know, it's the only pipelines out there that you can do Linux, Mac, and Windows. Do I have to create different pipelines for that, or can I just do one pipeline? No, you can. Or how do I use it? You can do one pipeline. Sorry, I interrupted. No, you're fine, go ahead. You can do one pipeline for everything. So if you see here the example of VS Code, this is just one pipeline, and it's building and testing for Windows, Linux, and macOS, all in the same pipeline. Oh, wow. So you can choose how you want it and how your teams work. If you remember when I showed the Rosalind one, they had created separate pipelines for different configurations. So there is flexibility to do based on what your needs are and how your team operates. Perfect, wow, that's really, really great. Well, Divya, thank you so much for taking the time. I mean, just somebody just commented, wow, that it's possible to do that. So kudos to you and the team for making it so awesome. Thank you for your hand. Yeah, there's a hand for you. Thank you. Thank you so much for taking the time. Okay, everybody, we are gonna be getting transitioned here. We have Orin and Ini talking about their migration of RavenDB to .NET Core. I'm really looking forward to this talk. It's gonna be great of some of the stuff that they're touching. So thank you so much. Stick around, we're gonna go to the slate and we're gonna get things switched around. Thank you. See you guys in a bit. Thank you, bye-bye.