 Hey everybody, stay tuned where Martin and I will be talking about GitHub, some of the new features and why IT pros should be looking at it. Hey everybody, my name is Sarah Lean, and today on Azure Unblogged, I am joined by Martin Woodward from GitHub. Welcome to the show, Martin. Thank you very much. Good to be here. Thanks for having me. Awesome. Today, we're going to be talking about GitHub from the IT pro or CIS admin type role, and I'm in that role, Martin. A few years ago, I used to think GitHub wasn't something that I had to pay attention to. It was a developer-only tool. I'm starting to become suede, and now I probably use GitHub at least once a month, if not more than that. Could you talk to our audience about why they should be looking at GitHub if they haven't already used it? Yeah. As we're doing more and more working towards DevOps, in an ops team, you have to work more and talk to developers more the way that they want to work, and that means often using version control and then using the collaboration environments your development teams are in. GitHub is obviously the one that all developers know and are in. But there are other version control tools as well out there. I think as an ops team, the first thing to get to grips with is just using version control. The number of times when you're sat there and you go over to the DBA desk and she's got a bunch of scripts that scrolled away that she's done over the previous years, and I had a script that did that 10 years ago. Let me take that script and change it and make it working with these particular tables and with this particular schema, or we're trying to deploy out to Azure, let's get an ARM template. We've got a similar ARM template over here, let's take that and use it. Getting all those resources into version control and then sharing them with your team is a big step, but at that source of the major part of the learning curve is just getting into a habit of versioning things by actually having version control rather than having v3, v4, v5 in your naming conventions and lots of zip files put around. Not that I'm guilty of that in the past, not running anymore, I definitely have seen people doing in the office. Then, yeah, go ahead. Yeah, I was actually going to say that was the first foray into GitHub for me because I had all those scripts that I'd built up Martin and they were spread over everything, various different Cloud solutions, USB drives, laptops, and then I thought, do you know what, GitHub's probably makes the most sense to put these, and now I can find those scripts, so you're very much right about that version control. That's how I would get the practice, because even just stuff things like yesterday, I was writing a script in Bash that was converting like a directory full of mob files into MP4 files using ffmpeg, and I can never remember the Bash syntax for a loop. Not that you would ever want to be doing loops in Bash, that's clearly explained, but I can never remember that. When I finally got it working in one line with a lot of semicolons and things, I'm like, right, I need to put this somewhere. I checked that into my personal GitHub repo, just so I've got it, so I can go back and grab it. Yeah. Get used to version control, do that, and then you can start, not only can you start sharing with your development teams and start talking to them and working in the same collaboration space, but when you had a real job before you came over here and working at Microsoft, you were sharing stuff with your teams, and if you've got them stored in a place that the team has access to, that the organization has access to, then you can encourage collaboration by having people be able to read code that other people in the organization are doing. So this isn't public open source, and people often have that misconception with GitHub, that GitHub is like, it's free, it's available to everybody. There is GitHub Enterprise where you can just share things in your team, but now you can share things in your team, you get a lot more collaboration happening naturally, because if you want to know how to deploy something, you know Bob upstairs has already done that deployment. Before I go bother Bob with dumb questions, let me go quickly have a look at the scripts that they wrote to do that, and so you go and you look at those, and then you can go and have that conversation seeing what they've already done, or maybe even not even have to have the conversation, you could actually just come in and just reuse best practices around the business and start to do that by because you've got this permissive read access inside of an organization. We're still very, very, very restricted right access, just because you're given in traditional source control systems, once you gave somebody access, they had read write access to source control, and that's very not typically how you do things with GitHub. You quite often get permissive read access, but it's very, very restricted right access to the person or the team that's responsible for that area of your system, and then they then can come in and you can send a pull request to them or do changes that way. I think that's quite key to that whole read permissions because I think I have been guilty of opening up a shared script, thinking it was my copy, Martin, completely blowing it away, and then the whole team is panicking because we've just lost something massive. So yeah, those permissions can be key as well. Well, that's how you know as an ops person, that's how you test if somebody's, if somebody's not, you just switch it off and see who's screened. That's definitely the quickest way. So yeah, with scripts, it's the same thing as well, but you can share it with the teams who's doing it and collaborate that way. And then once you start collaborating in code, by changing things in code, you can get reuse and you can try to start to encourage best practices in your dev teams because they're all doing crazy stuff and doing stupid select stars from tables and doing stupid deployments and all this sort of thing. But that's because they don't know any better and there's an ops team you can be coming in and really start educating the whole organization into the best practices and how to do things and start to template things and start to automate with GitHub actions and things like that. Cool. So in terms of Azure and GitHub, kind of mentioned GitHub actions, and I know I've used a bit to deploy some stuff to Azure, but how do they fit together? Do they, are they a great fit together or are we rubbing against? How does all that work really mark? All right, yeah, no, yeah. So it is a great fit. Obviously you would expect it to be. There's a whole team that, so there's different aspects. You've got parts of the Azure portal that they're actually able to integrate with GitHub and use GitHub for source control of things. So recently Microsoft launched the Azure static website stuff and that requires a GitHub repository to sort of deploy from and things like that. So there's those levels of integration from the Azure portal in. You can log into the Azure portal now with your GitHub credentials as well, which is a bit interesting. You know, you can link the two, your Active Directory credentials and your GitHub credentials, and you can kind of log in either way with both. But on the GitHub side, the major part of automation that an ops team wants to be most familiar with is this thing called GitHub actions, which is the automation engine. And there are a ton of GitHub actions for Azure. So the Azure teams create actions, so little bits of automation, which allow you to deploy to Azure environments to spin up virtual machine scale sets to do all those setup network in configuration, do all that stuff you do in an automated way. We can do that using these actions for Azure, which we have whole teams dedicated to supporting. But it's not just on the Azure side as well, because obviously all the other cloud providers have their teams that are building GitHub actions to their platform as well. So the advantage of GitHub is you've got this kind of cloud agnostic kind of tool really, but obviously Azure's fantastic, so it works great with Azure. Yeah, and I think when I use GitHub actions, I actually used PowerShell within my action. So I didn't have to, maybe that's not the best way to do it, Martin, but I didn't have to learn something new in order to make GitHub actions do what I wanted. So I thought that was quite good from my point of view being a non-developer. In fact, Christy, one of the MVPs, she's actually just done a whole raft of improvements to the documentation around using actions and PowerShell, because again, she's from the ops background just like you and kind of helping other people do that. And because the GitHub is GitHub, so the documentation is open source as well. And so she actually contributed that in and try and make that easier. So yeah, it's definitely a use case to see. I'm still not like kind of PowerShell is something I use when I'm not PowerShell native yet. I'm not posh native. I'm kind of just posh curious, I guess. Try and make myself use it when I can. Cool. I've had some buzz around GitHub code spaces and I think that's the right name. What is that, Martin? Is that something we should be looking at as well? Yeah, I mean, so GitHub code spaces is still in private beta. So if you go to github.com features code spaces, then you can go in and sign up and join the wait list. But basically what it is is a full development environment in the cloud for you to use. So if you've used to using, we're all, we're ops people, we're architects in the background. It's basically just, all it is, is just a container in the cloud that's using the dev container concept from Visual Studio Code. And then we have a front end from it, which then loads up that environment for you in your browser. So right from GitHub, you can come in and you can say, edit code in a code space. And then behind the scenes it's going, creates a container, loads it with the stuff you want, and then gives it back to you in the browser so you can start coding. And that gives you an environment like straight away. But the great thing is, is you can actually encode in the dev container, Jason, and then a Docker file and things, you can configure exactly what you want in that environment. So if you don't configure anything, you get what we call the kitchen sink container because it contains absolutely everything. But if you want a container that uses a specific version of PowerShell that's using specific versions of dependencies, because that's what your project means when it's deploying, you can bake them into your dev container. Not Jason, you can bake them into your container that's gonna get instantiated in the code. And then you know anybody that comes in and goes code new code space is gonna get exactly the same environment. And that's the way you as a team can roll out a development machine to your entire organization. And that's a full dev box that you're giving them access to that you're hosting in Azure, in the cloud, in a container. And so if you wanna set up what ports get forwarded or that sort of stuff, you can do that. And because it's a full container, you don't need to be giving people admin rights to their real machines. You're just giving them admin route access to this container instance. And so they can like from a completely locked down, you know, heck from a tablet or whatever or a really locked down, you know, machine, you can connect in and get a full dev environment that's running Visual Studio Code, debug, all that support just works. It automatically port forwards ports that run inside the container over SSL and authentication for you. So it's a really cool dev environment that I think will help a lot of our teams. And it really helps support use cases because, you know, you've got the problem where quite often you've got an application that's running in support and you don't wanna touch it because it's working and you've got like defects that are building up but you don't wanna go start fixing them because you know, you've got to pay that tax of getting everything set up. You've got a code space set up, you've got CI, continuous integration using Git of Actions and you've got CD, so continuous deployment. Again, using Git of Actions all set up on that repo calling code checked in alongside that code in the repository. You know, you can just spin up a dev environment in a couple of minutes, make the change, push that change back in, run all your tests, run all your deployment scripts and then it automatically go out. And so if you can get projects into that space then it's a lot easier to be able to maintain projects in the future once we go into maintenance. Awesome, that sounds very cool. I'm definitely gonna have to request some early access to that. Send me your Git of ID, we'll get you in. Awesome. I think it'll also be quite useful, I think, from what you were mentioning, from a support type of issue and a desktop engineer because often, like you say, you have to give someone maybe admin rights to their local machine to get all the extensions, everything set up and no one wants to be in that position. So being able to put it into somewhere like code spaces and have it a wee bit controlled and allow your developers the agility that they need is definitely something that I think lots of teams will be able to use as well. So that sounds pretty cool. And you could, if I like the container that's the standard, this is our organization container template that we use for our dev environments and then the team can come in and do local customizations to their container and all that sort of stuff. So yeah, it's gonna be really, it's gonna be really, really, really powerful. I'm really looking forward to this as it starts to evolve. Cool, awesome. So in terms of going back to IT Pros and why they should be looking at GitHub, where can they go and learn about using the tools and everything we've mentioned before, Martin? Yeah, so I think the first thing is to learn some Git and we've kind of talked in the past, learning by doing is probably the easiest way. Git is the most popular version control tool now, not for any merit of it being like the best version control tool. It's fantastically hard to use. It's like quite sort of illogical at times. And while the GitHub UI kind of makes that a lot easier by making you, you know, you can edit in the web and you can do all that sort of cool stuff. Knowing some core GITs and knowing how to, what's called clone or repository, let's get a copy of the repository locally, make changes, commit them and then push them back to the central repository. That's all good to learn. So there are a number of, you know, we've got the learning GitHub learning lab can teach you about that where we've got a number of interactive online courses over on the Microsoft learning lab as well. We've got some courses there. And then, you know, there's things like the pro GIT book and all that sort of stuff, which is good. But to be honest, just trying it, forcing yourself to use version control is probably the easiest way. And then you learn five commands you know how to do, like clone, check out, commit and push. And then you have to go to Stack Overflow and, you know, search the rest of them, like when you're trying to resolve some horrific merge conflict or do something like that. Either using UI, using like GitHub desktop or something or Visual Studio or, you know, the web or go, you know, Stack Overflow and answer. I'll tell you how to do it from the command line. Yeah, I think I have broken a few repositories and had to just delete them and start again because I couldn't fix whatever merge conflicts I had. And I have just learned how to use branches within GitHub. So it's definitely a big journey but I enjoy it by hands on learning. I think that's the best way. You remember your mistakes and hopefully don't do them again, Martin. Yeah, for sure, hopefully. Cool. Now I saw you on social media talking about prepping for GitHub Universe. Is that like GitHub's version of Ignite or is that completely different and I've got it wrong? No, no, yeah. It's all like, you know, we have sort of two major events every year. There's universe and then there's satellite. Satellite kind of usually happens in the non-virtual world. Satellite light goes around the world and happens in a remote location. And then universe is the main conference that happens in the other San Francisco headquarters. That's coming up as we're recording. That's coming up next week. No, not next week, December 8th. So yeah, we're pretty excited about it. A bunch of stuff coming out there. You can expect to hear more about code spaces. You know, we've been doing a lot of work around discussions and around actions as well. And there's some really cool stuff coming around the action side. There's gonna be a particular interest to, you know, your teams and helping people with deployments and all that sort of stuff. So yeah, some great stuff coming in and a few surprises. So should hopefully be a good conference. Get on universe.com if you want to go along. I always be promoting, I guess, this. Cool. Thank you so much for your time today, Martin. I really appreciate it. And hopefully it's been useful to our audience. Some of the information and resources that Martin talked about will be in the description box. So make sure you check that out to do your further reading. Remember to hit subscribe to this YouTube channel so you can get future episodes of Azure unblocked.