 All right. Okay. Welcome everyone to the sales enablement training for November 1st. We are going to do part two of the sales enablement for Azure DevOps, formerly known as VSTS or Visual Studio Team Services and TFS, which is a team foundation server. So last time we talked about kind of an overview of what Microsoft has in terms of Azure DevOps and kind of a little bit of fringe stuff around what is not Azure DevOps, but kind of still plays in this space. Went in a little bit more into detail about kind of the high level of what is in each of those different segments and a little bit about how that compares to what we have. Today I'm going to answer some of the questions that are a little more strategy-based that came up and we didn't get a chance to get to last time, plus go deeper into a discussion around what they have from a strengths and weaknesses perspective and really this is kind of the beginning of a discussion and I want to make that point very clear here that how we position ultimately against Microsoft's Azure DevOps is going to come down to what you guys find and encounter in the field, what we bring in from the market awareness and as a team put together an effective, you know, iterated, put together an effective response and a set of strategy to have them approach them. Right now we're looking at our homepage. I'm going to always start here because I want to make sure everyone's aware of how to get to the information that I'm about to show you. You want to get to the DevOps tools page, which you can get to by our main menu or if you are down here you can get to it by comparing all DevOps tools. On that page we've got the Azure DevOps through the comparison page for Azure DevOps. You'll note again I am running this out of my local right now. It's still pushing a change up to the main branch, but this will be probably by the end of this call live. On this page we are, this is where we're collecting information about this particular competitor. We talked last time on Tuesday about how Azure DevOps is really the rebranding for the most part of VSTS and TFS. I do want to point out a couple of things. I misspoke on Tuesday about whether or not pipelines was a new piece or not. It is not. I said that it was. I want to clarify that. A pipeline capability, actually two, have been part of VSTS and TFS since about 2015. They have build pipelines for running the CI side and they have explicitly, specifically different release pipelines for running the release side. The new pipeline capability is being talked about in Azure DevOps. The only part that is new about it is that they have made the default, the ability to construct those pipelines using YAML files and having your code, basically pipelines as code or processes code. That is actually also in VSTS and TFS was just getting released, but they have made that the default. The YAML defined pipelines is, again, it is from VSTS, but it is a fairly new capability. We will see as we look at the weaknesses or some of the things about that. It is actually not connected to a lot of stuff yet. Still a lot that you cannot do with it. That is an ephemeral. That is a very fleeting small window that we have where that is at least a weakness in that capability. Going back to that, to last week, there was also a question about whether or not there was a separate code base between VSTS and TFS. I have confirmed at this point, so I did hear from their project manager that it was the notion that they are actually taking three months or a quarter to release TFS after they released functionality on a three-week cycle with the SaaS service is kind of what was pushing us away from that concept. But in both the video by the folks who actually converted Microsoft over to use Git and in a write-up on Microsoft blog site right here, it is pretty confirmed at this point that it is the same code base. They say the two products are separate, but about 90% of their code is the same. One code base, but they are taking cycle time to produce an on-prem version. There were some good questions that came up that we did not get a chance to get to. Phil asked what does the migration path look like from Azure DevOps to GitLab from SCM and CICD. I answered that a little bit, but just wanted to point out that I have added more of that answer down here under comments and anecdotes. That is right here. They have two types of SCM capability built into VSTS and TFS. One of those is their legacy. I think I mentioned that earlier this week, the TF, basically the team foundation code management. That is a centralized service. It is part of VSTS and TFS. The migration from either of those is there is plenty of migration tools out there. It is well-established. Microsoft made their own because they moved all of their code over as well to Git. Once it is in Git, then getting it from Git to Git is not hard. The bigger issue is if someone is coming from their older centralized control or code control system to Git-based, to decentralized, and there is coming from any product, you would have this problem, but there is training to go through for the organization about how to work with Git, but that is something you are all familiar with at this point. The CICD migration is a little bit tougher. Their primary definitions for pipelines at this point are going to be done through the UI, which does not lay itself out as a YAML file. Maybe that is coming, but that is not there yet. Converting into Git lab would require doing a task-by-task breakdown in conversion when converting the pipelines over. Also, their pipelines are broken into, again, as I mentioned earlier, build pipelines and release pipelines as separate, whereas we do not do that. There would be a little bit more work to consider there, but not insurmountable. Joel also asked earlier, do we know how Azure DevOps is positioning against us? No, not yet. Doing some searches, there is nothing publicly stated about how they position us. What you can read through the tea leaves is that they are aware. They have anywhere where they talk about being able to import other competitors into their project. Obviously, they mention us without any issue. Where they talk about integrations, they definitely do not mention us. That is about as much as we have right now. This is something that we are going to learn over time as we engage them more and more. I need you guys to bring that feedback back in so we can centralize it and get it captured. What I do have is right here. This is how they are positioning themselves out at customers. This was out on the Internet. There is no proprietary mark on it, but I am going to switch over to it. This is their presentation, one of their presentations in Germany. It is pretty long. I am not going to go through it here, but it is linked. You can go through it and check it out and get a sense of how they are positioning. They are doing a lot about building credibility of themselves and how they transfer themselves over so they understand the challenges of moving to DevOps. They talk about the practices and how they can help with those pieces. This looks familiar. In fairness, this is on the DevOps Wikipedia page, but the rest of the deck goes through talking out each of these pieces in these four sections, plan, develop and test, release and monitor and learn. This is going to be a sense at least about what they are saying when they go in and they start talking about Azure DevOps to prospects. I will look to get feedback from you guys on what you are experiencing out there, and I will continue to work on building a way to talk against this or to counter this. This is what we covered in a pictorial version, what we covered last time. This is just no review. If we look at the stages that we subscribe, which goes by, and we place in it things like they have, for example, under verify, they have pipelines, but they also actually have test plans, so they get double credit there. This is how it lays out. Manage, we don't have anything yet. We are working on that. They have got MS portfolio management. It is not part of Azure. It is actually part of Office 365 right now. It is not integrated in, but it is a product that they have. They don't have anything under configure. This is a big point here right now, is they don't have anything under secure. They do have security operational services or products to help operation security, but they don't have code scanning or any of that built in. They work through integrations with the standard Black Duck white source, all of those guys. As a result, they don't have it tightly integrated, and you are hopping to different UIs when you go get the results. That is one of the strengths that we definitely have.