 Hi there and welcome back to another episode of Visual Studio Toolbox. I'm really excited to be here talking about a product that I actually work on in my day job and I'm here with my guest Jeremy. Jeremy, welcome to Visual Studio Toolbox. Hey, thanks for having me. I'm Jeremy Epling and I'm a group program manager on the VSTS team working on CICD, Git, and also going to be talking about some of the agile experiences today. Yeah. So Jeremy and I, we spent a lot of time talking to each other for my quote-unquote real job. But here in Toolbox, we love to bring great developer-relevant stories and Jeremy and I have a really fun thing to talk to you guys about today. So Jeremy, why don't you tell people just a little bit of a brief overview, like what are we going to talk about today? Yeah. So there's a couple of different things. First, we're going to start off looking at some of the new navigation experiences that we introduced to the product recently, and some of the feedback we've already heard, some of the changes that we're going to make based on that. After that, we're going to walk through some of the changes to CICD. So we've done some really cool things in our build and release views. So we're going to go through those, and then we're also going to talk a little bit about some of the agile changes that have come in, of how we split up the boards and have some new experiences there, and then I think you're going to wrap us up with another look at Azure DevOps projects. Yes, that's the goal today. So one of the things I want to make sure folks, I don't make assumptions about our audience. I think there's so much tools and so much noise, and so many awesome products out there. They might be like VSTS, what is VSTS? So I figured let's try to talk about what is Visual Studio Team Services, like Visual Studio Toolbox has often the IDE's and the editors, those kind of conversations and Cloud. But this is part of our DevOps stacks, and maybe you can introduce VSTS a little bit. Yeah, definitely. The way to think about VSTS is, it's really a collection of DevOps services that we have, and there's five main services when you think of VSTS. There is version control, which supports TFEC, which is our centralized version control system. But we also have great Git support with pull requests and all the features you would expect out of there. One of the other pieces that we have is obviously version control. One of the things you need to do before that is actually plan your work. So we have a great agile offering that has Kanban boards, queries, everything like that. Another piece of it is CI CD. So we have a stack where you can do continuous integration and deployment. You can deploy to Azure or any other Cloud. Works great with AWS or Google Cloud or anything else, and works great with any of the different languages, just like we've been doing with the client work in Visual Studio. So it doesn't matter if you're building Python apps or anything like that. We also have a product for doing manual testing and low testing. Then finally, we have a package management service, which allows you to create your own private package management feeds and use those if you need to have your own experience within your corporation. Yeah. So this product has been around for a long time. We've been working on VSTS that anchored in for Visual Studio Team Services for a bit now, and it even has a longer history. I mean, this started as an unprim product that we still ship and support today called Team Foundation Server or TFS. So maybe you can explain what happened there. How did we go from TFS to VSTS? What was the vision? Yeah, definitely. It started off like a lot of Microsoft products as like an unprim product a while ago. Then one of the things we saw and need is customers just want to go to the Cloud, and they really want a SaaS offer that's just going to handle a lot of those infrastructure deployment pieces for them. So we started off with TFS and we, over time, more customers were using it and loving it, and as we saw the Cloud transition, we ended up just refactoring TFS in a way so that it can run great on-prem, but we share the vast majority of the code and also runs in the service. So we have a great hybrid mode where whenever we add any feature to VSTS or to TFS, it goes in both places. Then with TFS, we ship a new major version about every year and then updates surround every quarter to three times a year. Yeah. So it's cool. I mean, we ship very often to VSTS. It's like every three weeks, it's a sprint release, so the features keep coming if you're a Cloud customer, and then every quarter or so, we try to push as much as it makes sense to push back downstream to TFS. Exactly. Really, however people need it, they can use it. I think that's pretty awesome. But I think one of the things we're going to really dive deep in today is, how has this product evolved? Just another level set for people that might not know. I mean, this is a product that is integrated with many other products. So like in Visual Studio, it's a Team Explorer experience, like you have places of IDEs where you're connecting to this product, but it also has this powerful web UI where you can do pretty much everything from the website, and I think that's what we've been realizing we need to make more and more investments. So maybe you can talk about like, how do we lead into this conversation? What investments are we making that we're going to show later today as demos? Yeah, definitely. One of the things you can see up on my screen here is a blog post that I did recently that talked about the new navigation experience that we're looking to do for the product and one of the things that we heard from customers is one, like the VST UI was functional, but it wasn't quite as engaging and as modern as they wanted it to be. So one of the things we've been working really closely is with our design team to kind of figure out how do we have a really simple approachable experience that feels really great. And then also looking at all the feedback we've gotten from customers over the years to see what tweaks do we want to make that would be kind of model level changes to make the experience a lot more approachable and easy. So one of the big things that you'll notice is we made changes in a couple areas. One of them is the overall visual style. We added a couple new elements and I'll kind of walk through these in a second in the demo. Across the product, we have a new left hand navigation that we've introduced that you can keep expanded or collapsed. And then we've also made it really easy to create those common artifacts because a lot of times you could be sitting there looking at a build, you find a failure, you want to file a bug immediately, we've got to click action just no matter where you're on the product to go file a bug and kind of get started with that. So we really want VSTS to be this blend of a great suite of services that interact really well together, but also allow customers to pick and choose which ones they want to use. So if you just want a CI CD service, you can use us and you can pair that with GitHub, you can pair it with Bitbucket or any other cloud provider that you have for Git. Your source can be wherever it makes sense for your source to be. Exactly, and the same could be for maybe you want to use Jira, that's fine, or you can use our Agile planning solution as well. So it's really this kind of best of breed service where you can do great things together but also use them independently. Yeah, it's an awesome thing, I work in this product so I spend a lot of time talking about it to people and I go to events, like you guys, we spend a lot of time talking to folks that've never seen it before and I find interesting that as much as we're making it super flexible to be the features you just want, like you said, you just want CI CD, you can just turn that on so everything else is kind of out of your way in this new paradigm, we're going to demo, but at the same time it does work great together and that demo is awesome and I show people who've never seen it before that you can go from like a work item that can be linked to a bunch of code that was checked in against the work item and then that code triggered a CI CD build that all the way went out to production and you can see that release tagged all the way back out to that work where it started and seeing that end to end trackability is awesome but it's also amazing to say, hey, if you just want one part of it, you can use it and we are very open to extend and go beyond. So this is super, I think exciting work and let's jump in and take a look, like what is the experience and I want to preface to say this is a preview experience, you have to opt into it at this point. Eventually this experience will come to TFS customers, we will make sure both products are consistent. So what we're showing today though is already available for folks to try but they have to go and try it, we'll show at the end how to enable that. So just wanted to point that out. So let's jump into the demo and take a look. Great, yeah, let's do that. So I'm going to jump over here and I'll start with what Dmitry just said, which is let's show how you enable this. So what you'll see is a banner at the top of your account. If for some reason you missed that banner or just missed it and want to check it out again later, you can go up to your avatar in the top right, click on that and go to preview features. And this is the way that you can see all the different preview features that exist in VSTS and you'll notice this one right here called new navigation. So you just click that toggle, flip it on and then you can immediately start using the new experience. Yeah, and one of the things I like to point out for folks who are really into their product is is this notion of like your account, right? Right now you're not in any particular project, you're on a much higher level of view, maybe you can talk about that. Yeah, definitely. Yeah, so one of the things that we do is we want to have a great landing experience for people to get started with their day. So in this account, I'm in the Regis organization right now. As you can tell, I work at Microsoft and we use VSTS for all of our internal projects. So there are a lot of internal organizations that I'm a part of, but in this case I'm using kind of one of the demo organizations that we have. So one of the things that you'll see over here is there's kind of three main pivots on this view. One of them is the projects. So you can see a project that I've been to recently. There's a nice big card for that. You can see all the different services I'm using. And then down here is the list of all the other projects in this organization. So if you need a search, you can go up to the top right here and filter through the projects. I can click on any one of these and you can actually see on the right when it does this cool little animation which services are enabled. So again, it gets back to what we talked about before where it turns out on this mobile CI project I just needed CI so I can use that and kind of simplify my experience just to those services or I can go up to these bigger ones. One of the other pieces of it though is it's not just about jumping into a project. Sometimes I wanna see a view of what are all the things I care about. It's like when I'm starting my day, I wanna know what are the work items? What are the pull requests? What do I have to get done today? So in the top right, we have my work items experience. And this is actually something if you're in our preview is not there right now but we're actually introducing. And it was something that was based on a bunch of customer feedback where they're like, hey, I really need these experiences where I can see across things. So I'll go to my work items and I can see a couple of these work items that are assigned to me, the state that they're in. I can click right on them and jump right in. And because this is a picture at the organization level, it also tells me which project they're in. So I can't get confused of what that is. Then if I jump over to my pull requests, you'll see that I'll also see pull requests that are assigned to me. And then if I had created any happen, I hadn't created one before this. You could also see the ones that I've created. So I can kind of see both sides of that. And this one has a little blue dot to let me know something's changed since the last time I was there. So if I click into this pull request, it will actually show me at the top the couple of things that have changed. And then over here, I can see that it's a new pull request, the number of comments, who's working on the pull request. Just basically just think of this as kind of your to-do list when you wanna get started for the day. This is everything that I need to get done in this organization. Yeah, and this complexity, I don't want it to overwhelm people because at the end of the day, that left hand side will be completely empty if you're in just one organization. The point is though that we can scale all the way up. And I've had people say to me, well, is this only for big customers? Like is this for like the enterprise scenario? And I'm like, I'm one guy, and I use this for all my source code, for all my like planning of the work against the source code for my CACD. It works for me just fine. It's free for up to five users. Folks are surprised to hear that we have a free tier. They think, oh, I used to pay for this or it's part of some VS Visual Studio thing. I'm like, well, the name is associated, but it's its own product. It has its own free tier. Go check it out. And this, I think, proves my life a lot if I was working with you guys day to day kind of on code and on planning work. So that's kind of awesome. I even learned a few things. I didn't realize that in one of the screens you were showing, someone was like, oh, yeah, I didn't notice that, even though I stared this now. Yeah, almost every day. So that's really awesome. So okay, so now you've gotten to the point where you understand what your life looks like. Let's jump into the product and take a look what the next level of depth is. Let's do that. So I'm going to click into a project and immediately I'm brought to the project summary experience. So I kind of get an overview of what's going on in this project. This is actually something that was in the old experience, but there's a couple areas that you'll notice that are new. One, this whole left-hand nav is new. So in the current product, it's kind of a blue strip across the top that tells you where you are. One of the things we've done is brought it over to the left side. This allows us to kind of scale more and to get quick access to kind of everything that we have. So over here on the top left, I can see the project I'm in, this Fabricam Fiber Web Project. You can see that I've got overview and that's where my dashboards are. So things that sort of give me a view across all the services that are enabled for this project are all kind of in the overview. So like my Wiki could apply to what we're doing with our CI builds versus what we're doing with work. I can come down, hover over work. You can see I can get to the familiar work pages around seeing all my work items, boards, back logs, for code, a similar set of things, build and release CI CD. We talked about tests and then finally package management. So you can see kind of these five major services that we have across the product. And one of the nice things is like I was saying before, no matter where you are in the product, so I could be on any one of these pages, I can click on this plus button up here and just go ahead and file a bug or create a work item from anywhere. Because very common kind of activity people do all the time. So that's the quick access bar to it. And then one of the other things we've heard is that sometimes people would get kind of lost in the product because there is a lot here. So one of the things that we've done to correct that is to have this breadcrumb up at the top. So you always get an idea of where you are. So you can see I'm in the Regis organization, Fabricam web project, and then we call these top level items over here services. So kind of like I'm in the work service, the overview service, and then I'm on the summary page. And if I were to go over to work, you'll notice the overview closed because you don't really need that anymore. We expanded work. And then you'll notice the breadcrumb updated to say, okay, I am in the work page. And then the page under that is work items. And I can see all the different work items that are on this page. One of the things that you will notice though as you move around the product is sometimes you kind of just want more room and to kind of immerse yourself. So if I go over to boards, we have a great boards experience here. But sometimes I just want to be able to go edge to edge with my board. So one of the things that we've done is make it so it's really easy to collapse the left hand nav. So if you want to be in this kind of collapse to minimal state, you know the product really well, you know what the icons are, you can still hover and get tooltips on them. But you can really get into that immersive view of what's going on with my board. Yeah, let's crawl them in more of the productive space. And then I guess you can still go fully full screen like in some of these experiences with top ride. Exactly. So you can really even take over more. Yep. More of the space there. So that's cool. I mean, let me ask a question. Like, did you guys just decide to do it this way and just woke up and did it? Or was there more of a process? Because I know that a lot of times people want to be part of these things hosted in the cloud. They want to provide their feedback, make sure it's executed on. They think we're trying to do a lot more of that. Yeah, definitely. So I'd say this process started probably around like January, February. And it started with us just really looking through all of our customer satisfaction data. So we use this thing that promoter score NPS. People probably be familiar. Anybody here that's ever gotten one of the pop-ups that's like, do you like the product or not? We actually do read all of those and look at the feedback. I start most of my day is actually looking through all the verbatim comments and seeing what people like or not about the product. So one of the things we did was we saw consistent feedback around how do we improve the navigation and how do we just improve the performance, which has been another part of this. And then another piece around just kind of modernizing the visuals. So we looked through a bunch of those. We actually contacted a bunch of people who set their marketing preference so that we could contact them, did a bunch of interviews with them, ran usability studies. This was probably the fourth iteration of this design as we were testing it with different people over a couple months. We went and built it. We launched the preview in June. And since then, we've actually gotten even more feedback. And like I mentioned on the last page, that my PRs, that my work items, that was a major piece of feedback. A couple other pieces of feedback we've gotten is changes we've made to teams. So VSTS has this notion of projects. Inside a project, you have a team. And one of the things that we've done in the agile space is actually make a change here. Before, we used to just have a backlog page over here. And it contained kind of your board was in there and your sprints. And a lot of times, people were kind of confused because it was this very much an amalgamation experience of multiple different things. So we split those up. But then we noticed from talking to customers that it kind of introduced a different set of problems. So one of the things that we're working on now is trying to figure out, how do we respond to that feedback and make sure that it's still really easy for people to switch between their teams and kind of keep that context if you work that way. Yeah, we definitely listen to all the feedback. So it's really helpful, whether it be Twitter or blog comments or the NPS results. And whenever you turn off a preview feature as well, you'll notice that we actually ask you why'd you turn it off? And I can guarantee we read all of those too. Yeah, I mean, I get that question asked a lot. Like, do you guys read the feedback? Do you follow the feedback? Was something influenced by feedback? Like, yes, across the board to all of those. And even the experiences that are in the preview and it's a preview for a reason, we still don't feel like we've gotten it. Like it's not nailed and it's working perfectly. I mean, forget like bugs behind the scenes, but even in the experience that we are trying to redefine, we haven't figured out 100% how we're defining it. We're looking at people's feedback and we're continuing to evolve that definition. And that's part of our done state of calling this thing complete, if you want at some point. Definitely. Like when I look at like my commitments, like up to my managers, it's all about like how satisfied are customers with the product. And like, I don't really consider a change like this done or a change for any feature done until customers are really happy with it. And that's, like you said, it's kind of like the core exit criteria, if you will, for like shipping a great feature is like, do people really love it? And if it turns out we shipped something and it's not doing great, we're committed to keep working on it and tell we feel like it is great. That's awesome. So in this experience that we're showing, I think you started with sort of like my view, but the view continues to be available to you, right in the top right of the nev, so maybe we should show that. That's right. Like that's one of my favorite changes. Yeah. So just like you were saying, we have this kind of global navigation. So on the left, this is kind of things you can do within the project. So all the services that are enabled are creating things. You can click the VSTS or Visual Studio Team Services logo to get back to that page we were on before that shows all my projects. We have the breadcrumb bar across here. On the right-hand side, you can search and this searches across the entire project. And like you were saying, we have this notion of this kind of to-do list of my workplace. So one of the things we heard is not just having it on a separate page is what people want. Like some people want that and they want a URL that they can just bookmark to that. But a lot of times people just need that quick access no matter where they are similar to creating a work item. So what you'll notice is we kind of have this peak view here where I can see my work items, my pull requests, and then also all of my favorites right here, which looks like I probably forgot to set one up before the demo. No problem. But we can go through and we can favor one over here. And then the other thing that I have is a link to the marketplace. And then before we show this, which is my avatar, which is like all of my core settings related to me. Yeah, and also in that avatar, that's where we can enable this preview experience. So maybe we can show like whether it's one more time just to make sure people know. Because it's easy to miss. It's one of my top ask questions. Folks say, where's that thing that you guys talked about in release notes? Or did you just treat it about like, this is where you go and this is where you go for everything. If it's available to you. And this list will be different for even different people, right? So some people will have more items because they're in kind of more deeper preview rings of our product. And then engineering has sometimes the most. I see some people having quite a few. And then we have these enabled. And you can always opt out. That's another very key thing. Like we understand you need to get your day job done. And also what's the scope of this new navigation? So if I have like my work VSTS and I have my private one, can I switch it out for one, but not the other? Will I impact other people in my organization if I turn this on? Is there any fears around that? Exactly. So just like you said, we roll out features based on rings. So sometimes you'll have access to some things and other people won't. But yeah, I can specify how I want to turn on a given feature. So in this one, it says for me, like Jeremy Eppling. So in this case, I would just be toggling these on for me and only me. One of the other things I can go do is go do it for my entire organization though. So in this case, in this demo organization, I don't have permission to go do this. But if I did, you can see there are more features over here and I can go ahead and toggle these on for the entire organization. So in this case, I'd be forcing everybody that's in this Regis organization to turn on the new nav or do something like that. But only if you had permission. But only if you had permission, that's right. Yep. Okay, yeah, that's awesome. I think they'll give people some sense of safety in trying these features on knowing they can turn it on for just one particular account that they're in and not have to worry about their work account or other people even in the same account being impacted if that's that's right. Cool. So we've not only made improvements to, like you said, to the breadcrumb or the favorites or the navigation, we're actually making improvements to the individual screens within different parts of the product because of course we hear that even they need to be modernized or improved. And maybe we can go for a few demos of those. Yeah, that'd be great. So we can start right here on the agile board and then we can go over to some of the CICD scenarios. So awesome. On this one right here, one of the things that you'll notice is we've kind of simplified some of the top navigation. So if I have multiple different boards that I want to go to, I can click here and quickly switch between those and whichever ones I favorited will be at the top. So I have quick access over to those. As you saw me do earlier, I can quickly favorite any board. And then if I go over to my list over here, let's go away, come back. Oh, looks like that might be taking a little longer than I hoped. I tend to file a bug. Yep, read yourself. And then another thing though is kind of what else is going on with my team? So let me click over here on this icon and it'll show all the related artifacts for that team. So I may have a board, I might have a backlog, I could also have a sprint. So you can see all the different things. So I can quickly move in that team context between things. And then I can also see who are all the members on the team. So this is something else that we've added new. So again, trying to have that person centric view of the world and not just kind of the different artifacts or landmarks within the product, but also who are the people, what are they working on and how do they all relate together? Because a lot of people like to think about things both ways. Yeah, makes sense. One of the other things that we've done is we can go over and show some of the work that we've done in Build. So this is another preview feature that's only on for kind of a limited audience. But we've been updating a bunch of the UI in our Build experience. So one of the things you'll notice is I have a Build pipeline over here on the left. And then I can see which branch it's building, when was the last time it was built. Over here I have a history of kind of all the different builds. And in this case I can see that there was kind of a scheduled build running here. So I can click on an individual build. And this gets to our new build results experience. So one of the things you'll notice, especially for you to our old one is we've definitely cleaned this up and modernized it a lot more. So we have some nice cards so it's really clear to see what's going on. We have this new timeline view, which is something that I'm really excited about, which kind of gives you an idea of what is everything that's kind of going on with this build. So actually let's jump back over to one of these other ones. And in this experience you said it's on for a limited number of people, like what does that mean for people watching this video? When can they give this a try? They're excited. Yeah, one of the things that you'll notice is and some of the things I'm demoing today are still only for the engineering team when we're rolling them out. So for this one right here, I would say in our next Sprint's deployment, we're gonna have a preview that's gonna come out for people and they're gonna be able to start checking out. So in the next couple of weeks, it'll be available to everybody. And we have release notes. We'll make sure there's a link to the show notes where we in a very detailed way put all the top features in the release and we even have a little videos. So lots of ways to learn about what's shipping every release. Definitely. So here's another one to look at. So in this case, what you'll notice is I can have a list of all the different commits that are in this change. In this case, I was just building the same thing that I had already built for a demo, but it would list all the different people and the commits that are in that change. Then I can see, okay, that's kind of the first step in the timeline of a build. Then I can go through and see this build process and I created one with warnings just so we can get an idea to see what that is. So it'll pull out from the logs the exact warnings that came out so I can quickly make a decision there. If it was all green, it would be fine. In this case, I've configured my build to succeed even if there are warnings. If there were failures, you'd see them bright red right there. So as soon as you come in, you know exactly where your build's failing. So again, it's all about trying to draw people to the action that they can take. Awesome. So it's a bottom up kind of timeline. Yep, yeah, exactly. With the latest on the top, kind of like a feed style. And then a lot of the times once you've built something, you want to get to one of the artifacts. So in this case, this build produced a couple different artifacts. I can go ahead and download those artifacts. I could also click here and do it. Yep. And then if I wanted to kick off a release from this, I could just click over right here, kick off a release. One of the common things people also need access to though is the logs. So in this case, the way I set up this build was I'm actually kind of doing two build jobs at the same time. So you can see both of those jobs over here. I can go through and see everything succeeded. If I go and click on any one of these, it'll actually slide open. And this is actually the Monaco editor. So this is the same editor that's actually in VS Code. So you'll notice we automatically have syntax highlighting. We have a mini map over on the right hand side. I can jump between the different tasks that are in the build. So it's a really easy way to kind of go through my logs. In this case, I'm doing something simple. As you would imagine, like some people have very complicated builds with lots of logs. And having a lot of these features from the VS Code's core editor makes it really easy to navigate and get through those. Yeah, I love how we're sharing code with that team. I mean, that work started, I think, with moving one of the first places to use it at least that I can remember back in the day. So it's kind of cool. Definitely. It became an amazing code editor too. So let's jump back over to the timeline. And then one of the other things you'll see is that I actually kicked off a release based on this. So we'll go over to the release. Yeah, so it's worth kind of pointing out again, just to level this up for some people that this is like two distinct capabilities of our product of VSTS. You haven't used them independently or they were great together like this. You can build your code in the cloud and you can choose to stop there or you can even choose to make it a continuous integration. So it's constantly building and checking based on how you configured it. And then we have release management or what we always often call RM. And this is that release management side and they're connected. But again, you could have used either one independently. Could have built with something else. Some other competitive product took the artifacts and released it with our product. So there's lots of flexibility, but these are all tied together. And if you want to use them that way, so that's kind of what really awesome. Yeah, definitely. And we definitely see a lot of customers do that that have a current CI system or build system they're really happy with, but they need a more mature kind of deployment product or already using VSTS or something else. And it's a great way to like connect those two things together. And then over time, a lot of those customers will choose just to use VSTS or stick with what they have and they like. And even on the CI build side too, you can bring whichever like build runners that you want to that. So obviously if you're a Gulp build, we can still orchestrate that through our system and do everything else. So yeah. Yeah, this is one of the new views that actually was in the release notes recently. So that we can show status of different releases. So one of the things you'll notice is I have an artifact. This was triggered off a specific build from VSTS, but this could have been a Jenkins build. It could have been anything else that like created this artifact. And then you can go over here and see I deployed it to Azure. In this case, it triggered a failure just so I could show that in case there's a failure if you just needed to, you could go through and redeploy. One of the other things that we can go and do is actually edit this release or even just edit the entire release pipeline. So I'm gonna bring up this pipeline view and what this does is kind of shows some of the other things we have. So we have this is like how your release is configured, right? So these are the various steps in the journey of your release going from the artifacts all the way to environment and this view lets you manipulate that configuration. Yep, exactly. So one of the things you'll notice is on this specific stage kind of of that journey I go through here and I can say, hey, I've got this release that's happening to Azure. It has three phases. It has seven tasks. I could dig into what those are. But sometimes for more mature, I would say customers that are going through and doing deployments they'll have different conditions they want. So different things have to be met before a deployment can happen or after a deployment happened. Maybe you have a set of people that need to approve from it. Maybe you wanna set up a set of gates that can basically trigger things where you're gonna be monitoring health over some period of time and you wanna kind of run that over time. The release gates is a cool feature. It's something we shipped fairly recently so a lot of people still don't know. It's in there in the settings but having the ability to gate and we even have like the marketplace extensibility of it, right? So people can even build their own gates against this and make decisions what protects their builds and how they deploy super option. Exactly and like some of the most common gates that I see in some we use even for deploying VSTS is we use VSTS to build and deploy VSTS. Yeah, we've got inception going on there for sure. Exactly, different things around health monitoring and you just wanna check it on an interval to make sure everything's going well and then maybe after a day of doing that or an hour of doing that or whatever you think feels great then you can progress to the next stage of your deployment. So maybe you start off in the internal environment and you go to kind of a pre-prod environment and then you go to prod and it gives that kind of flexibility so you can do that. And just like you have pre-deployment conditions you can also have post-deployment conditions and these are also gates and approval so those same kind of extensibility API points you mentioned before like an integrate easily into both of these. And then if you need to you can always go through and create more environments and I'll just go ahead and create one here. We'll just stick with. Yeah, that list that dropped down we passed it quickly but it's very comprehensive there's a lot of stuff in there people can choose from. Yeah, let's do another one as you can see but yeah, as you can see we have a lot of different templates and you'll see a lot of Azure IIS on here but there are many other templates and we can deploy to just about any service. So you can see one of the most interesting ones that I'm working with a lot of customers on right now is Kubernetes, which we have right here. So, you know, if you do container based deployments and you go to an Azure service that's great we support you or if you wanna go directly to Kubernetes because you're hosting it on a different cloud or you're hosting your own hardware and wanna deploy directly that way we support that. And again, all these templates are driven completely from the marketplace so people can build their own or you can contribute your own and then see how popular it gets up on our marketplace. Yeah, it's very cool. And you can build really interesting complex environments throughout here as well. So I can go through here and say that this depends on both of these environments and just have different interesting configurations like that. So it really allows people to kind of do this notion of kind of fan out and fan in across their system. And then one of the things we didn't touch on quite yet was also the test part of the product and then the artifacts or the package management side. So those are two other pieces if you have manual testing, if you have load testing or you have a need to have your own kind of private registry of internal feeds that you're using within your company. Maybe you wanna ingest things from the outside like open source, have it in but only lock to specific versions. You can go ahead and kind of do that in a safe controlled way to make sure security, whatever protocols or compliance protocols your company has are met on there. Yeah, and it's cool that I mean, package management just like every part of our product is very much looking to be open and inclusive. So we're like supporting Maven and NPM and you get like, we're not, this isn't old Microsoft. There isn't just like only our products thing in there. It's pretty much looking to be anybody's package management solution. And we're looking for all the feedback from the community to make it better. Exactly. Awesome. So I think this is a great set of features and with this, I wanna segue to one closing demo that I'm gonna do for my machine, which is to talk about Azure DevOps projects because this is something your team builds as well. It's part of the ABSA portal inside of Azure. So people ask me, what is this and how does it compare to VSTS? I figure let's use this moment to talk about another great UX experience that lets you set up CICD pipelines and really explore multiple products and our cloud together. It's kind of a set of things that it helps you configure. So Azure DevOps projects is inside of the ABSA portal. And I'll switch over to the ABSA portal here and we'll have a link to this page as well so you can learn more about it. But this is me logged into Azure's management portal. And in here, if I say to myself, right, so I wanna create a resource. One of the options I can do in the create is type in DevOps and DevOps projects will come up. And DevOps project, when I hit create over here, it will show you that it is a tool that lets you kind of chain together a bunch of things that creates an end-to-end CICD pipeline. And you can use this to learn about configuring CICD pipelines. You can use this to explore our product VSTS because it creates the repo, the build and release part of that pipeline. So VSTS is the CACD engine and where the Git repo is stored for this. Think of it as a way to again learn. And then you connect it over to App Insights which is our ops piece which can monitor the deployment. And you have a target, so you're gonna aim this thing at a particular resource on Azure. And that's the resource that is the final endpoint. I'll show you, it takes a few minutes to build all this out. So I'll show you how to work through it and then show you all the pieces that it's connected to because this is I think a really awesome way for folks to learn CICD or explore the various products that are part of it. So here on this first screen, you have an option to choose what is my starter application? Now, this is not gonna be locked for you. So I've seen people ask me like, okay, so let's say I choose Node or Python. Let's say Python in this particular case. Does that mean that the only thing this thing ever works for is that sample Python application? Well, no, it's gonna be checked in into a Git repo. You can right away check it out, make changes, check it back in. If the build doesn't break, it'll build, release, deploy, and be out in the production endpoint. So it's kind of cool, but let's choose Python as a starter experience here. And then the second thing is that, just like most runtimes, there's some kind of framework, a UX framework or some choice that people have. And again, if there's a fourth one that's not on this list, you can check out from Git and replace the whole thing with whatever you want. But we right away out of the box give you some popular templates that Python developers would be familiar with, Django in this case. I've used them for so many demos over the years. And here's where it gets interesting because now, and we're constantly evolving this feature to say, all right, so which runtimes do we support? Which frameworks do we support? Which services can we deploy to? All of this, the list keeps getting bigger. Right now, for Python, it supports web apps for containers, and that's gonna be a Linux-coasted container, or you can just deploy to just like a web app on Azure that's not a container-based environment. But if you go to something else, so for example, let me show you Node, if you were to choose Node through this wizard, Node actually supports Kubernetes already. So we're adding Kubernetes to this as well. And again, this is an awesome way. This is how a lot of people are learning how to actually set up a Kubernetes deployment through a CAC pipeline for a particular language that they're interested in. And again, this is all end-to-end wizard, like if I go through these steps, let's go through them for the first one I selected. So let's choose Python again, say next, Django, next, let's say yes, I'm fine with the Linux container for it, then it's gonna ask me, now, which VSTS instance do you wanna use? And at this point, if you never even use VSTS, you can go ahead and create a VSTS account that's gonna be your CIC orchestrator, and you can name it right here. Or in my case, I have one already, so I can go ahead and select my particular one at the bottom here. If only I knew how to scroll, there you go. So, and then I just need to give it a project name. So Azure DevOps PD-01, let's call it that, just to be a demo. So this will now link my source code that I selected, it will put it into a repo and it'll configure a CAC pipeline in this account that I selected inside of this project, and it'll deploy it to Azure, to this particular region. And in that region, it will also instrument it against application insights, so that you can monitor the release. So in this case, I'm gonna pick the west region and I'm just gonna hit done. And as long as I didn't choose something that was incorrect, you know, a reserved project name or something like that, it will let me go forward, and it will start creating the resources. So, within less than 10 minutes, you're gonna have all this stuff deployed. And it's really powerful, there's even some database options being added to it, so it's a really cool way to do it. I'm gonna jump into one particular place that I recreated a project. So, if you click into this project, we have, again, investments in UX. We're trying to make it easier for our developers to be able to understand what exactly is it that they are managing in a visual way. So here, we show that there's code that's checked into a repo inside of VSTS. The builds are happening inside of VSTS, and VSTS supports Mac, Linux, and Windows builds, so it's choosing the right build, and we support containers and Kubernetes and our release. So our release is pushing this out. And from here, you can literally click on one of these. So if I wanted to see the source code, I can click in, and here you go, it's opening VSTS for us, and it's showing us the code, it's showing us a code diff, there's so much rich features there. And then if I wanted to see how the build's doing, I can click on builds, again, jumping out to VSTS, showing the build view, the one that we were just talking about a second ago. And all of this, all the experiences that Jeremy was covering as something that you could do from VSTS itself could be pre-configured here, and you can jump in and take a look at the end. I have my releases configured and all the way out to a website that's gonna be up in Azure. In this case, a Python website, I even changed some code and the pipeline kicked off again. I added some exclamation points, because I love Azure. So it's really cool, and it's not a replacement for VSTS. When people ask me like, is Azure DevOps Project the replacement for VSTS? No, it's another UX inside of Azure that makes sense in Azure. And I think we'll see more and more places where VSTS plugs in over time into parts of IBS and the management portal. But just wanted to show this off because I was excited on this UX day to show some more cool UX our teams invested on. So that's it. I think that we covered our agenda for today. Yeah, thanks for everything. No, that's everything. Okay, awesome. Well, thank you folks for watching. We hope you enjoyed this episode. Please leave us your comments. You can follow us on Twitter. We'll put all the links and all the show notes. And please give this a try. Give us feedback. We really are listening. We hope that you'll use our DevOps products and thank you for watching again. Have a great day. Definitely, thanks.