 Hi there, and welcome to another edition of Tuesdays with Corey. If you hadn't heard, we're back. We took a seven or eight month hiatus, mostly thanks to Rick. But we are now back, and we have some. I know, I throw him under the bus right away. Because the beautiful part is that he doesn't have a mic. So there's nothing that can happen this way. That length is suspicious. Hiking the Himalayas? I know. Exactly. So we are back with an awesome topic. A great example of how we are expanding out beyond just the realm of Azure into a lot of different areas. And today, a particularly exciting area in GitHub. Well, thank you very much. Hi, I'm Matthew McCullough, and I lead Field Solutions at GitHub. And what we want to talk about is how dev and ops and SRE and developers are getting closer and closer and closer together. And they have some competing concerns, but I think there's actually a way to make those harmonious. Harmonious? Yes. It's an exciting word for an exciting topic. That's unpacking. I'd love to. And so what you're saying is that we've got all these roles, and today they fight a lot. And you're going to show how we can avoid them from fighting. They do. And let's talk about a couple of reasons why to start the stage. Go. Ops wants consistent. They want controlled deployments. They want it managed. Of course. Because, of course, they're responsible for the outcome of the application. That's right. And all developers need to do is move fast and break things. I thought I saw a poster one time, right? So just produce a lot of code. Finally, we're seeing that those two might be at odds and there's a middle ground to meet. So we want controlled deployments. And I think a lot of things, even our CEO, Nat Friedman, says, ship to learn. And that's actually a better way to think about software development. You're learning all the time. If you're not getting better, stop. You should be improving. So what are we going to do to that? We're going to put a little bit of automation into our workflow and our deployment. We're going to talk about Azure deployments specifically today. And we're going to zoom in to GitHub Actions, as it means to do that. I'm super excited. And you said, so we'll talk about GitHub Actions. We'll talk about it in the context of Azure. But it is not limited to Azure. It is a multi-cloud capability that you're going to. Did I ruin already the surprise later? The secret weapon. I'm sorry. We have the cape down. I'm sorry. I'm so sorry. Okay, fine. I'm going to shut up and let the great show some now. So that's a little bit of the frame. It is. Should we show a little bit of what you had in mind? We should. But we should add one more reason. Why? Sorry. It's a multi-cloud solution because we really believe in the Azure solution here. We have friends that are not all in on this yet. And it's actually great to meet them where they are. I think it's kind of a corporate culture here. So if we have the ability to deploy to multiple clouds, we can bring some of those into the family. Absolutely. That's my motivation. And look, I think it's not even whether there, it's a lot of customers have the plan to be multi-cloud forever. And that's great, right? That's no problem. We want to be able to support them in their endeavors and make sure that they've got single tooling that they can use to be able to accomplish those goals. So I'm excited in all the ways. So we're going to first head over to a page because I want things that the audience can touch and see. I love it. So github.com slash features slash actions is the entry page so you can do more reading. We're not going to read your slides. Do you want to read the slides out loud? Well, I could. But I feel like they're pretty good at that. We're going to let them do that on their own. Exactly. But this is a workflow management system. So let's set the stage. Okay. We're going to zoom into a specific part of it today, which is just a round deployment. But you can think of triggers like a contributor license agreement. Corey, have you signed the agreement such that you can contribute to this project? It could be there. But it can also be for deploy. Okay. It can be for issue management. Corey, you have an issue open that's been for 21 days or is it eight months? I remember that. It's eight months. The issue. And to sign a REC right now. It is. Okay. So we can have it. I reassigned it. I reassigned it. Perfect. So it can be on that. Yes. But then we're going down to the specific deployment. Okay. Today. Now what I'll tell you is Microsoft is a huge contributor to this as our US and as is GCP as well. But we're over in Azure slash actions. Okay. So we can see the work that outside contributors can put into this action system right these little modules, Lego bricks. So that they work with whatever those, whatever that environment may be. Got it. Issues or deployments. So here's the page where you can view some of that source. Pretty cool. It's open source. You can dive into it. But we're here to look at how it actually works. Love it. Now for the deployment ones, we can get a specific detection. If it's a type of JavaScript application like, you might at least see a little recommendation that said, would you like to use this? Yes. But you can also dive in and specifically pick them. If we had labeler, for example, we can dive into that particular action and just apply that to our particular project. Now I've got one set and ready to go over here. We're going to slide over to the Azure bookstore application. Okay. Shout out to VTor and Alarm for helping me set this up over the last couple of days. Okay. And this is deployed out to Azure websites or will be very shortly after we discuss this. Okay. So right now it's, it's, we're still, we've got to, we're not ready yet. On the edge. Ops is set, hold on for a minute. On the edge. Okay, great. Exactly. And I want to talk to you through the syntax before we do that because it's kind of the reverse of a magic trick. I want to show you how the trick is done and then I'll show you the magic trick at the end. So opposite of usual. Okay. We're going to go into a .github folder over here. Okay. And there's a couple of file formats and there's an extension. You're going to love .yml, yaml, familiar to so many in the Azure ecosystem. Anybody using pipeline to the like would know that as well. Yeah. We're going to drop into deploy yaml to take a quick look over here and this is part of our configuration. Super easy to read. We've got the groups. We've got the name for the different environments. Key value pairs. Perfect. But there's no answer yet. We're just looking at text of how those environments interact with the code that I'm changing and that's going to be part of the reveal in a moment. So I'm going to ask you to kind of hold that. Hold questions until the end I think is what you're telling me. Maybe you're just hold that thought. Okay. The questions can flow. The questions can come. Okay, great. Then we're going to go over into workflows which is another piece. This is where we define these behaviors on an action system. Or yaml files, build, clean up, master deploy, deploy to QA or deploy to test. Configuration free. We'll just drop into one just for the sake of example. Slide down to this. Pretty easy to parse this. You don't need a user manual. That's what the yaml fun is about. Deploy to production with all the exclamation points. That's right. It's four exclamation points. And it's got Ubuntu. I hear that the overall Microsoft ecosystem is now much friendlier with Linux. So Ubuntu is... That's right. Is that official? That is official news. Since soon we're going to have like a Windows subsystem for Unix, Linux, something like that. Yeah, we don't talk about that. Okay. I thought it was released. Yeah. No, it is actually. That's right. So now for... Yeah, it's for you actually. Great. It's in there. So we've got that. That's where we're deploying. So we're going to slide over here. And this is basically our build system. So should we just make this happen? Yes, we should. We're going to go to the top level of the project, Azure Bookstore. And we are going to immortalize you by dropping it over into the source file. And then over into main, and then over into the web app. Got it. And then over into books.html. It's going to be a lazy change. All of your audience is going to go, Matthew does not know how to code. He's breaking the HTML. What is he doing? But I'm sliding down right over here to... Let's put it over here in the title. And we'll just say Tuesdays with Corey, you're going to be so famous. This is on the internet. So... Don't get removed. So this is serious stuff. That's serious. I mean... Tuesdays with Corey and number two, because this is take number two, if you will. Okay. It's always better. It's the second version. We're going to propose the file change on a branch. Okay. And I'm going to slide over here to labels. And I'm going to pick a deploy to test in this particular case. Okay. And now what's happening here when I create this pull request is a couple of things. By this label, just a ticketing system, if you will, to this change, this pull request, we are sending signals that can be captured by those Lego bricks as we call them to the workflow. And you'll see that I added that deploy to test and the robot. I love when robots do my work. I love bots. You too? I do. We share that. Well, I love the little hands too. I think that they... They're perfect. They're perfect for typing. And so what you've got in this particular case is commit status checks failed for Tuesday with Corey too. And so what I wanted to show with this particular piece is that the bot is interacting not just with the code that we changed, but in fact the labels as well. Based on the label, it's doing different things is what you're saying. That's right. I got it. So what's the value of this? Let's talk about the value prop for just a second. We've made this human approachable to do devs and ops things again, which was our first premise. Right, right. Which environment do I want to go to? I need to change the parameter and hold my hands a certain way, make sure I change the config. No, just apply the right label. Just put the right label and the right behavior happens. And it's grouped. Exactly. That's cool. Super easy to approach. So this will maybe do like a more significant level of testing or more so, okay, got it. Perfect. And we can even simultaneously deploy them, but I already warmed this up over at the top so I can show I did a master right before we started this build so we can save our time. And you'll see in fact that if I click my way over to this, we have the master branch still nice and stable. And this is the beautiful contrast. I blew up. So you're still going. Test. Yeah, yeah. And I've still got prod in a beautiful state, but I'm working out of a single repo. One of this which repo or macopying and pasting and moving it to a second one to do the other deployment single source of truth, right permanent history and record with the issues everybody working together. You can tell what the which code has gone to production, which code has gone to very, very cool. So you know that my putting my name into it, you can quickly identify that that broke everything. It wasn't going to say it, which is I get that feedback a lot. So that's good. I'm going to leave that to you. Thank you. I'm going to be kind and gentle. That's nice. I'm going to ask, you know, do I have any visualization though? It's nice that there's all this magic, but come on, give me a, give me a lens, give me a view of some beautiful Azure dashboard into this. Here's a beautiful GitHub dashboard. We think alike. So when we're looking through this, we can see all the workflows. We can see the same named ones that went through in the individual files. We can see the deployed QA or review app or the deployed production. And the prod one came a little bit earlier. I've triggered that one six days ago to get that nice and clean up stage. We can look at some of these. And if we want to go into a build a feature branch, let's dive in and even look specifically why this thing blew up. We can dive into any one of these. And we can view the workflow file, view the pull request, cancel the run if it's still running at that point. And on any of these, we can also look at the time that it was built, who was the person that did the build. And last but not least, I want to take you over to one more piece on this, which is the ability to go way back in history so we can scroll back over here. We can go to previous times and we can filter this by particular users too. So in this case, I can just narrow it down to the ones that are Matthew. So what does this give you? An audit log. This is back to Dev and Ops. Yeah, of course. Meeting together. Give me some logs. Give me some history. Exactly. Let me query what's happened in the past and find the intersection of those two things. So that's really what I intended to show you at the top level. What else have you got from the point? I mean, that's awesome. So I mean, I basically just to, oh, so one question, you know, one of the other things that, so moving fast and especially from an Ops perspective, sometimes securing and making sure you've got your credentials in a good place is a challenge and sometimes a place that people get tripped up. So I'm wondering... You can almost read my mind. Wow. So what we do is we go to the logs. It is a skill set of mine by the law. Because the password is printed in the logs. That's the perfect place. Back. We can reuse it. Got it. Oh, wait. That's the opposite. We're not supposed to do that. That's not what we want. So I'm going to show you over here that it is sanitized. When we expand out any of these stages. This is the build log itself. You'll notice that if there is a place that I took a environment variable, an important word, environment variable, and paste it in here. You would not see the password exposed because it is a special type of environment variable called a secret that can be used in the build. Some folks will now scrub back in the video. They'll see the little parameterized environment variable for password in there. Yes. And that is set under settings. I'm going to slide my way down over to secrets and you can see that we supply you with a very simple key value secret store. There you go. And the beauty of this is that you have users. Let's say you're a super user, you're the biggest boss over here. You'll be able to sub these. You're paying the bill for the Azure consumption. You don't need to let the rest of the team actually see the value. They can just use it as an environment variable. And then you can manage sort of roll over and all that stuff happening in the background as needed. The people who develop against it don't need to know or care. Again, splitting the needs of ops and the needs of developers into sort of these two roles, but again, having a single source of truth. And you have permissions such that you can divide those responsibilities and yet they're playing in the same space. Got it. Got it. So it's almost as if their badge gives them the proper permissions. Yeah, yeah. Very cool. So that's it. Front to back. What do we see? We saw that Dev and ops can meet in the same repo. Yes. They can deploy to different environments and keep production stable, happy, happy. But still a single source of truth. Absolutely. Move fast so they can be doing that test in QA and then it gives ops a lens into what's coming because it's in that same place. Well, also giving an audit log going back in time. Absolutely. By-person filterable queryable. I've been tensioned. This is good. This is good. This is going to be successful for you. This is going to be good. You're going to have a demo out here pretty soon. And then you can see all those history. We can see the one deploy that you've done in the 92 that I've done in the past test rate over here. Thank you. Yeah. It's not a competition. That's right. The issue that was open for eight months versus the one that mine was open for just a few minutes. And then lastly, down the security credentials over here, we can store these as key value pairs. Again, with access control based on that. Right. Everything you just showed works no matter what cloud you're deploying to. That is one more reveal that we can take right over here. Yes, it is. We're going to find our way over to actions and I'm going to click over into the deployment category. Sure. And so if you look at the URL over here, github.com slash marketplace, we're thinking of this even though you don't pay individually for these actions. Yes. We're thinking of this as a shopping for the behaviors that you need in the system. Yes. And we do support all of the clouds out there, whether it's Heroku, AWS, GCP, of course, strong support for Azure. And the beauty of this, again, is you can actually do a matrix build and a multi-cloud deploy. And you can deploy any of those clouds. So it is not a binary choice. Right. It is a maybe all of them. And then again, it comes back to that single source of truth in your code, but deployment options that can go anywhere. You can even say test goes one place, production goes another place. And no problem. Exactly. And if you're trying to test your path and move over to Azure, you can imagine that you could have production be a different cloud. Totally. And already getting yourself in that habit. That's right. So that's it. Matthew, what a cool set of things that you just showed. I think we're going to, there's a lot of other things I feel like we probably have not yet dug into that we're going to need to have you come back and talk about more. Hours. And I would love to. Hours. Hours. Hours. We will, the next Tuesdays with Corey will be a three-hour long show. Yeah. It's called the Marathon Edition. The GitHub Marathon Edition. Yeah, exactly. I like this. It's a pleasure. Thank you for the time. Yeah. Awesome show. Awesome set of stuff. And thank you for joining us. Let's go back and have an awesome set of demos. If you have any questions for me or for Matthew or about the show, hit us up at a new tag phrase here. Tag phrase. Is that what we say for Twitter? A new tweet thing. That's what the kids say. I think we say tweet thing. A little tweet thing. Hashtag TWC solutions because we're talking about all solutions now in Microsoft. And ask us questions, comments, give us feedback or new topics. Or. Hashtag GitHub or hashtag Octocat, our mascot. There you go. And those are tweet things too. So just FYI. Thank you so much for your time, Matthew. Thank you. And have a wonderful day. Thank you, Corey. Thank you. You got it? You want to do it? Let's do it. No, you got to do only one person. So you got it. Because it grits a whole bunch of confusion if we both clap. All right. Are you ready? Okay. I'm going to do an intro such that this could also be just the first show. Just based on the quality. In case we need to read it. In case we find that this is a higher quality show than the other one. Setting the bar. Setting the bar. Wow. I need a moment. Take it. Just breathe in. It'll be okay. But you've got a lot to live up to. All right. You ready? All right. All right. All right.