 Today on Visual Studio Toolbox, we're going to continue our look at the future of Visual Studio, and this time we're going to look at team productivity. Go team! Hi, welcome to Visual Studio Toolbox. I'm your host Robert Green and joining me are Amanda Silver. Hi. Anthony Candelosi. Hello. And Kendra Havens. Hi. And we are back for part two of our two, possibly more, episode series on the future of Visual Studio. So previously on Visual Studio Toolbox, we covered personal productivity and cloud productivity. Yeah. And today we're going to do team productivity. That's right. Yeah. Excellent. So team productivity is... OK, sorry. Go team. Team productivity is super important. I mean, everything that a developer does is generally working with somebody else in that same project. So I think what we've really been focusing on is how can we make collaboration when you're debugging something or when you want to get a code review, really, really, really as focused as it can be. So that your team is much faster in terms of the time to market that they're trying to achieve. So we have a couple of different demos that we wanted to show you guys. But I think what we wanted to start with is just like a reorientation back to what we talked about last time. So Anthony, take it away. So I think last time we were talking about how annoying it is when you have a bug that you can't reproduce locally, but of course our customers are finding in the production. And we were just showing a demo of time travel debugging and because it's so cool, I kind of want to show it again. Absolutely. Should we jump into the demo? Okay, cool. So this... And just to remind everybody, we are using previews of upcoming versions. Right, that's right. Yeah, so there's no smoke and mirrors. This is, we'll see what we get and we'll see which demos work and which ones don't. But so this is the Smart Hotels app that we've been using for the last couple of months. We've got this feature that is the best rooms and is trying to find the best rooms in the hotel so that you can kind of sort which rooms you might want to book in. And obviously here I'm seeing a list of rooms but our customers weren't seeing it in production. So what we were able to do is actually get a trace of the production environment at the time that the customers were reporting the issues. We actually have all the execution and memory at that snippet of time. So I can actually go back and debug that and see what was happening for that customer. So let's go ahead and load that trace into Visual Studio. I'm going to drop a little break point right where the page loads for that and then let's kick off debugging a record, a previously recorded process. So here's the trace that was recorded of the production environment but I'm loading it into my local Dev environment here in VS. When I start that, VS will go into a normal debug mode. I can actually hit break points and what I'm seeing here is this loads up is I'm actually going to execute the code as it was running at the time that the customer went through it. So this is a break and now I'm seeing the locals windows in the bottom with all the memory in the state at that time. I can naturally step through as you'd expect over different parts of this. I'm loading into all of the hotels at first and here now you see my update of count of hotels. It's finding three hotels out of all the ones we have to look through and then I'm going to go and call this function that should calculate for me the best hotel. So if I step over that, let's see how many returns. Okay, so here now it's showing me that in production there's only three or there were three hotels total there's only one left. So now I think I'm pretty close to my bug. Now, if this was a real debug environment you'd have to kind of stop debugging, go back kind of reset up the whole repro to make sure you get it without having any side effects but instead because I'm debugging a trace I can actually go and step backwards. So I'm actually going to step back into that last call that I made. So using this new command that we're introducing called step back into and this is actually reversing the execution. So instead of stepping back into the top we're stepping into the top of the functions you normally see we're actually coming up the bottom of the function and I'll just keep stepping back and you see now all the locals are just unwinding. Go ahead and go, it's still cool. Something we've been working on with Microsoft Research actually. So it's not just like your standard issue call it's like extra special call. It does not get old. My favorite one is this one here where I just kind of step back and I want to run across back to the beginning so I can drop a break point at the beginning of this for loop. I don't have to step through all of it and then we have a new command that is reverse continue. So if you continue forward across the loop I can reverse continue back to the beginning of the loop here and now I'm positive beginning all that time we're winding and now from here I can slowly step forward and see what's going on in my code. Pretty cool. So let's step into this loop. Love that. Let's see. Okay, so I've got this method here that's calculating our best hotels and this is doing our calculations. Let's start stepping through this here and it looks like it's probably something in this comparison that's comparing between the ratings of four and five stars. So let me invite my partner into a live share and I can actually do a live share in the middle of this trace debugging to have my partner take a look at what's going on and help me figure out what's happening here. Nice. Pretty cool. Yeah, so let's see. So we're taking demo bits on top of demo bits combining them together and see what kind of chewy goodness we get out of it. All right, so I've got a live share session started and I'm gonna switch over to teams and I can paste that link for Amanda to come and take a look. All right, Amanda, do you mind taking a look at this bug that I was seeing in production? So now all I have to do is go ahead and click on that link that Anthony sent to me and it's going to bring up a webpage that will figure out that what I want is to load a code editor and for me I wanna load Visual Studio 2017 so I'm just gonna say yes. And then after that, it's going to actually start up Visual Studio but not just start up Visual Studio as normal. It's actually going to start up initiated by the context of the live share session that Anthony has. Now, usually when people see demos of live share, it's like, oh, I'm doing this code, I'm doing this co-authoring, co-editing experience. But what you're going to see here is that we're actually going to join in the middle of a context of a debug session. Now this isn't just a normal debug session. This is actually a debug session that's back in time. Right. Right. So it's actually something that was caught on a production environment and a trace was captured. So I'm actually joining his session now in debug mode for something that happened in production a while ago. Not right now. So as you can see, as soon as it loads, I'm actually, I can see his cursor where he's at. I actually am broken at the break point that he has and I have the full debug experience that you would expect so I can expand locals and look at this and see the value of count, things like that. So if you'd also be able to go forwards and backwards, right? If you had a version of Visual Studio that supported that? Theoretically, yes. So I can go ahead and go forwards and backwards in time in terms of moving the debug cursor. We have not yet done the work to actually take those backwards buttons and the reverse continue buttons that Anthony has and make those available in my context if I'm in a time travel debug session. But that is definitely something that we want to do. Oh, yeah. So he's got a feature Visual Studio that you don't have but you would potentially make that available. Well, but the cool thing is that like because we have a shared debug cursor, he can basically progress the debug cursor however he wants to, including going back in time to show me what the bug is. I wanted to show you. Yeah, let's take a look. So I'm gonna step forward here and we should see that all of our memory is updating and I see that we just stepped over down to the bottom of that method because it didn't match that comparison. I can just keep stepping through. Now from here, I'm gonna step one more time and then I'll step back. All right. I should be able to step back over. And now as I go back, let's see we're going backwards. And even though she doesn't have the demo time travel debugging bitch, she's still tracking my cursor wherever it's going. Yeah, and the same thing with all the memory updates. You'll see all that happening in local's window as well. Yeah, all the values. So what's the problem? Okay, so we're seeing here that- Oh, that's right. Yeah, that's what we're talking about. No, it's just you were trying to do it. I just thought we were doing cool. No, that's great, okay, thanks. Hey, wait a minute. You can just watch that cursor go back and forth all day long, right? No, so we're trying to figure out why it is that our get best hotels method here isn't returning any hotels. And I think that's something to do with this if statement here that is comparing the hotels of four and five stars. Okay, so basically if I look at the rating here for this particular value, so we should be able to get, and I see it's a three, okay? But then if I look at that and I look at the rating, I actually see that it's 4.3. So if you see the code that I have here, it's actually checking if it is exactly four or if it's exactly five and that was a rating of 4.3. So my code has a bug here. So how should we fix it? Well, why don't we actually fix it right here and then we can run some unit tests and see what happens when we make sure all the tests are out of pass. Okay, let me stop debugging. All right, well, since we're in a live show, you can actually make that change yourself and make sure it's working. Yeah, so I guess I'm checking to see if it's greater than four and also less than five. All right, so let's see if that works. So now I saved it. Anthony should see it directly in his version. I'm gonna do a rebuild. And then once that's rebuilt, I'll start off a shared terminal and from this shared terminal we can actually run our test cases. So as soon as he brings up the shared terminal, I actually also see that shared terminal coming up in my session. My hands weren't even on the keyboard. I didn't touch anything. Like I just got that context because he wanted to share that with me. This is just so cool. Yeah. So you want me to do the... Go for it, yeah. Let's just go ahead and... Cause everything you type I see on my terminal as well. Let's see. So move to tests and then I want to just run our .NET tests like that. And we actually are going to see in real time the results of the tests for this change. So it's building. And we can see that the text execution is starting. Yep. And if we're doing the simulcast share, we should see that both of the screens are updating all the same company. Right. So we see that successful. So now, now remember like I don't have, I don't necessarily have any of the context of Anthony's code on my machine. Right. You don't have the code. You don't have the test local. You don't even necessarily have the same features he has. Right. I might not even have the SDK dependencies he has. He could be building an Android app and I might not have the Android SDK on my machine. So, you know, it's really cool. And the other thing is especially when you're collaborating in a team environment, like how many of the, you know, debug sessions, collaborative debug sessions you've had are due to developer configuration. Right. Like configuration on the dev box. This isn't just like a terminal that's specific to this project. This is actually a real terminal that has complete access to what's running on his machine. Yes. So I can use it to inspect environment variables or do whatever I want. Obviously that comes with- So be careful, kids. Yeah, exactly, be careful kids. That definitely comes with, you know, some security. Like you have to be comfortable with who you're sharing it with. But it does really allow you to debug a whole bunch of issues. And we've seen even internally folks using it inside of Microsoft that a lot of reports of people just talking about how helpful it has been just for the context of being able to share a terminal. Right. So that's pretty cool. So then, so let's just jump to the slides real quick just to talk about live share. So what you guys saw was, oh, let's see, there we go. So what you guys saw was that basically in with Visual Studio Live Share, you can use the tools that you like that are configured for you. So for me, I'm using Visual Studio, Anthony's using Visual Studio, but we could have used VS Code, right? And we could have had narrator settings. I could be using the dark theme, like whatever it is that makes me super productive. I get to use the tools that I'm super productive in, whereas if in screen sharing, you're really kind of like bound to the person who is sharing the screen with you, right? How annoying is it when, I mean, even when you call support, for example, and they wanna take over your machine, and sometimes they get access to the mouse, sometimes they don't, and then you give them control and then you can't really touch the screen because you have to like negotiate who has control over the mouse and the keyboard. And that just happens all the time for developers. So this really makes it possible for you to use the tools that you love that are configured for your use. You get immediate real-time collaborations. So if I type a little character, Anthony sees it pretty much immediately, we have the full context. So not only do we have just one file that I can see, but I actually have the full context of the project that he's working on. Without having to duplicate his environment. Right. Which could take hours, days. And that's super useful because for me to get my bearings to help somebody, it sometimes requires that I do a little bit of spelunking around their project to kind of understand what's going on, right? Versus the four and a half minutes or whatever this took, where you worked it out, found the problem. This was definitely a streamlined demo, but like most of the time, you might be talking about a problem and it's like, hey, I think it's here, but this is somebody who's asking for help, they might not really know, right? And so you might need to actually go and look at other files to figure out what's going on. And with this, you don't have to ask them to like open the solution explorer or open up a folder. Like you can go ahead and inspect all of that yourself. And then obviously we showed debugging together. You know, LiveShare today supports debug sessions. What we showed that has not yet been released to the world yet, but is coming is being able to debug together in the context of a time travel debugging session, which I think is pretty cool. It's awesome. Yeah. Very, very cool. Yeah. So I think we talked about all those things. So the next thing that I want to talk about is shift left. Have you ever heard of the concept of shift left? I have, but why don't you explain it for those that have either not heard it or may think it means something different? So basically it's the idea that like, there's a lot of things that go on in the developer process that might not be part of what we would call the developer inner loop. So basically the edit debug cycle, edit debug build cycle, things that happen, like code analysis or unit testing that might happen after you've done a build and maybe even asynchronously with your application as you've built it. So what we are aiming to do is to make it so that we can bring more of those processes earlier in the process as possible. That's what we mean by left, but they happen earlier in the development process so that you can find and remedy issues much, much quicker, much more quickly. So one of the things that we've been working on is actually bringing PR experiences directly into Visual Studio. That would be nice. That would be good. Because today you can start the process, but then you have to leave Visual Studio and go over to the SDS or GitHub or wherever you're going. It would be nice to have it happen inside Visual Studio. Right, or to some command line or something like that. Yeah, exactly. So if we go back to our instance of Visual Studio where we fixed this bug earlier, so now what I wanna do is basically take that code fix that I just made and apply it to set a code that I've already been working on and then actually commit it as a PR. So I'm just gonna go ahead and copy this directly from the session that Anthony and I just had been working on and I'm going to go to my other project. This is actually my local repo of the same project that I've been working on some editor fixes for. So you can see that I have four different changes across various different files and I'm just going to replace this line with the code fix that we just made. And you can see that it's less than four and also greater than four and also less than five. Going to save that and let me just close this instance of Visual Studio back to this one. And then what I'm gonna do is go ahead and just look at those changes and what you'll see is that it's going to bring me into a diff mode. Now we've had diff for a little bit in Visual Studio but this is a new kind of what we call a ubiquitous diff experience where you have. You've had to go find it before. Yeah, you have the, it kind of comes up automatically. I can not only see it in side by side mode but I could also see it in inline mode so we can actually see that edit there. And it basically allows me to commit that right here so I can just go ahead and do some style cleanup plus ratings bug. And I can go ahead and commit all and push. And then, so it's pushing to the current branch which is all basically happening locally but now you can see that I have this new link here to create a pull request directly in Visual Studio. Yeah, so now it kind of lets me go through all of the different changes that I have. I can go ahead and add Anthony there, add him. And because Kendra has been working on some of our tests for this, I want to add her as well. And then I want to go ahead and create it. Is there anything else that I missed? I don't think so. So I'm just going to go ahead and create it. A lot of fewer context switches. You're doing this all in the same place. Yeah, exactly. So that's kind of the idea. So now let's go ahead and switch over to Kendra who can review this change. Yeah, so let's say I'm happily coding over here in my machine and if we want to go ahead and switch to my screen, yep, there we go. I'm happily coding away. And let's say I get a notification since I was added as a reviewer to Amanda's pull request. I can actually go ahead and open this pull request that I was added by and it switches all of my context. You kind of saw the output in the window. It pulls Amanda's branch to make sure I am actually reviewing the right stuff. And now I'm getting this pull request discussion message that I now see what PR she gave. I have a pull request comments window. If I go over to the solution explorer, you might have noticed this new little icon up here. This is my review filter, which I can toggle to see only the changes in this PR and all of the files that have actually changed. And I know we talked a lot about IntelliCode in the previous episode. IntelliCode can also come into the PR experience here. You will see a little new icon because IntelliCode has actually reviewed this PR and it can mark what files are interesting or what have had a lot of changes or get a lot of traffic is saying, hey, this is an important file you might want to pay more attention to as you're reviewing it. And that's actually based on AI. It's machine learning models that we've looked at a whole bunch of different PRs to understand kind of like what represents risky types of changes. And so based on that model, that's how it selects that indication as to which files you should focus on. Yeah, so this file I can see in the UBDF had a lot of frequent changes, but I can kind of tell, okay, this was actually just a lot of code cleanup and refactoring as Amanda mentioned before. Though I'm not too worried about this file since I know it was just code cleanup. So now I can look in the pull request comments and IntelliCode also has a suggestion right here. So let me go ahead and change to inline mode so we can see this a little bit better. So IntelliCode left a suggestion right here. Here I'm using an Ionumerable. Well, I'm creating an Ionumerable of a subset of a review list only looking at recent reviews here. And then when I go into the for loop, I don't actually use that sub list. I'm still using a larger set. So IntelliCode was able to see that right away and say, hey, that's kind of inefficient to iterate though, right? And it is even suggesting what I need to rename it to. Cool. And I only have to click a button to apply that fix. And it renamed it from reviews to my recent reviews which would be a smaller subset of that list. So that's also something that we've been working on with MSR. Basically they've come up with brand new machine learning science, you know, new graph theory to identify different types of bugs that basically cannot be found with static analysis. So this kind of opens a whole new door of types of issues that your ID could find for you. Yeah, that's great. Yeah. And as soon as the fix was applied, the state changed to resolved, which was pretty sweet. So I know that there were some tests that were changed with this PR. So I want to go ahead and dive in to look at those. And I can see in this PR context, live unit testing is still running. So I'm still getting my live unit testing glyphs, even in the viewer. So I know that it looks like Amanda had updated this test to reflect the new results. So see we're kind of adding in a float here and everything. So I can actually set a break point in this PR that I'm reviewing and start debugging this test. Holy cow. It's kind of our big wow moment. Wow. Maybe I should have set it up more, but yeah. So I can hit that break point and actually step through my depth viewer. That is cool. Pretty insane. Okay. Yeah, so it's a great experience. You've got debugging, you've got IntelliSense, you've got live unit testing glyphs, you have dot completion all inside of a PR experience. And we even have IntelliCode also doing the smart suggestions in the most likely code completion patterns we want in this area. Yeah, pretty sweet. Yeah, so the thing that we're really trying to do here is to make sure that Kendra as the reviewer can be as productive as she can possibly be in that code reviewing process because code reviewing takes a lot of time and oftentimes it really takes a lot of time, particularly for senior developers, because they often get the bulk of the reviews that they have to do, right? But when they do a review, oftentimes the only thing that they're able to do is like a cursory glance at what's going on and like, hey, LGTM, right? It looks good to me. But with this, because you can actually run tests, you can use code navigation, you can actually debug and maybe even change some things, you can actually see what's going on in that PR. And you're actually conducting a real live code review. And different from your browser, yeah. But because of IntelliCode, first of all, you have even more confidence that some bugs are being found, but you also are able to focus your code review more on the files and the changes that are more likely to cause issues. So that we hope is going to make people a lot more productive in their code reviews. Definitely, that's cool. So that's really all we've got for you today around team productivity. I think next time I wanted to show you how Visual Studio lets you do any app and any platform. Absolutely. I'm always up for a part three. All right, cool, sweet. Cool, very, very cool stuff. Thanks guys so much. Thanks. Hope you enjoyed that. And we will see you next time on Visual Studio Toolbox.