Are Codespaces inside of GitHub, or is GitHub inside of Codespaces? Yes. Both of these things are true.
GitHub Codespaces provides a cloud-hosted, containerized development environment powered by Visual Studio Code.
In this session, we’ll show you how having an editor hosted within GitHub gives us a unique opportunity to enable rich, productive GitHub workflows without ever leaving GitHub itself.
Join the Angular Community: http://www.ng-conf.org/ Get your ng-conf tickets: https://ti.to/ng-conf Follow Us: https://twitter.com/ngconf Learn More: https://ng-conf-school.teachable
Read More: https://medium.com/ngconf
Hear More: http://theangularshow.com
Follow us on twitter https://twitter.com/ngconf Official Website: https://www.ng-conf.org/
Hi, I'm Joe Eames. Thanks for checking out this talk from Reliable Web Summit 2021. Online conferences were great, but it's time to get back in person, see old friends, make new ones, and take your career to the next level. Our parent conference, ng.com. Comp, is back and in person on August 31. Head over to Ngcoff.org to get your ticket and stay tuned for information about Reliable Web Summit 2022. Now enjoy the talk. Hey everyone, thanks so much for joining this session on GitHub Code Spaces. My name is Bridget Murtal and I'm a program manager on the Visual Studio Code team at Microsoft. So how I kind of like to kick off this session is asking you to think about what is your ultimate developer dream. When we think about starting on a new project or contributing to something for the very first time, you may be thinking about, okay, I have to go ahead and clone the source code to my local machine, or I need to think about what dependencies and languages the repo requires, and I need to download them on my machine or take some time to figure out what versions I need. And all of these are totally fair and typically what we need when starting something new. But with GitHub Code Faces, you no longer need to worry about that. With Code Spaces, they're both inside of GitHub, and GitHub is inside of Code Spaces. So let's go ahead and take a look at how Code Spaces work and how you can be productive using them. So if I navigate over here, this is going to be an example of a project that I want to go ahead and start contributing to. So I can see that I have this app and it's called a group calling sample, and it's this really cool application where I can go ahead and have these calling sessions with my friends. And I can see here as I'm scrolling through the prerequisites similar to what I was describing at the beginning, I'm thinking about, okay, what do I need to go ahead and get started with this app? I can see that it has Net Core 3.1, and that's going to be a pretty fundamental requirement of this app. It also uses other things like NodeJS and Azure, and even taking a look at the code structure that's explained it looks a little bit complex and intimidating. And normally I'd be thinking about, okay, how do I need to set up my local machine and my development environment, and how do I clone this and set up everything so I can really get started? And how long is that going to take too? But with Code Spaces, we no longer need to worry about that. We can just go ahead and hop into a Code space and pretty much immediately start being productive running our app and start contributing back to it. So there's a couple of different ways you could start up on a code space for a specific project. We can use the code drop down menu and start up on a code space in the Web for this project. We can also use Desktop Visual Studio code and go ahead and use the Code Spaces extension. And we can also go to Kev. Comcodespaces and we can see all the code spaces we already have across different repos and create new code spaces at this point. So I'll go ahead and create a new code space from this page. So I'll go ahead and choose a repository, and I'm going to choose that communications app. Okay, here it is. And then I can choose some other information, like which branch I want to create it on. I'll just create it on the main branch. Now I can say create good face. So when we start it up, we're going to see that it's building this container environment. And essentially you can think of code spaces as these developer boxes in the cloud. They're initially going to be built on what's known as the kitchen sink image, and kind of like the name would suggest, the kitchen sink is going to include a bunch of different languages and tool sets directly out of the box. And so they're going to include things that we think that a lot of different developers might need to run their apps and to develop and become productive. But they're not going to be quite fine tuned for this specific project. But I should be able to start contributing back in some way. So we'll see what's included. I'll exit out of this notification for now. And we can also see here that, for instance, it is running this command called post create command. A little bit, we'll take a little bit more of a look at what different commands mean in the world of containers, since that is involved a little bit with code spaces. But essentially it's just going ahead and setting up this kitchen sink image. That way it has all the dependencies we need. And now we can see that our theme even changed within our code space. And that's because it does take advantage of other Vs code features like setting sync, so it can sync in the environment and even the theme that we use locally. That way we really get this smooth, familiar experience that we already know in our local Vs code to become productive in these developer boxes in the cloud. Okay, so we can see that our environment has been set up and our code faces gives us this nice, welcome message that tells us we are on that default kitchen sink image and includes different runtimes and tools to help us become productive. So let's go ahead and see the wide set of tools that it comes with. We could even see the full extent of them at this link, but let's just see a couple of them. So, for instance, do we have Python? Yes, we do. And then I don't see Java on this list. But let's see, do we have Java? Cool. We have Java installed as well. So it's that easy to go ahead and get this developer box where I didn't need to install anything. And I already have so many different languages that I might need to go ahead and start running or contributing back to different projects. So one of the first things that I want to do is just go ahead and try running this app. So what I want to do is go ahead and navigate over to the run and debug view. It like I would in typical desktop via code, but I can see here that I don't really have a run environment or a debug environment configured yet. So I could maybe try creating a Launch Jason or if I click on this, I could see the different options here, but I want to take a step back and think a little bit more about what is the proper next step here. So when I take a look at the files here and I think about how I want to configure my code space next, I had mentioned that we're on this kitchen sink, which does include different languages and tool sets out of the box. So for instance, I know I needed.net we have.NET version five, which is great, but I believe in the README. It said that net Core 3.1 is really the prerequisite here. And I think that I don't really need all these extra tool sets like I don't really need Python or Java to make this application work. So that's where the next part of using Code Spaces comes into play, which is known as development containers or Dev containers. So Dev containers are going to allow us to further customize and fine tune our Code spaces environments to really make them applicable to our specific apps and use cases. And Dev containers are going to ensure that anyone else who goes ahead and works in this environment is going to have the same exact development experience when they work on it. That way it doesn't just involve us specifically setting up certain tools in this terminal or in certain files and then leaving it so that our other colleagues have to do the same when they set it up. We're going to ensure that anybody who works on this repo is going to be able just to hop in and have the same environment no matter what. So in the lower left here where it says Code Faces, I can click on that and I'm going to click on this option that says Add development container configuration files. We can see here that it already seems pretty intelligent because it's detected hey, maybe you're working with NodeJS and maybe you're working with C Sharp and there's even a variety of other options and I could say show all definitions and even get some more options. But C Sharp sounds pretty good for me for creating a customized environment. And I can choose a specific version of. Net. I'll choose 3.1 because I believe that's what I saw on the red me, and then I can even customize it further. So I remember that I do need NodeJS in my customized environment, and I don't think I need the Azure CLI. But if I wanted to, I could go ahead and add it later. So I'll say okay, and the code base has already picked up that we've changed our backing environment or container in some way. So it tells us, hey, we've noticed a change to your Dev container configuration should go ahead and rebuild the container to apply those changes. I will rebuild it to apply the changes, but not quite yet before inspecting the files. So I'm going to hold off for now. So we can see here that we've now added this Dev container folder. Let's explore the files inside. So if you're familiar with dockerbased development at all, a Docker file may sound familiar to you. And inside we can see that it's first pulling from and it's going to pull from an image. Now, an image is essentially just going to define our environment, and it's pulling an image from the Microsoft Container Registry or MCR. And a registry is going to be a collection of images or a collection of different environments that we can choose from. And then we can see that we can go ahead and install NodeJS, and we can even choose to install the Azure CLI. I'm going to go ahead and comment on this one for now. All right. So now that we have the Docker file inspected, let's take a look at this devcontainer. Json file. So even if you're familiar with Docker files, the Dev container JSON may still seem new to you. And so the defcontainer. Json is essentially going to tell code spaces or any sort of vs code environment how to spin up and connect to a Dev container. And so it's going to have various build properties and settings within it. So you can choose a name for our container, some different versions and properties. Like, for instance, did we want to install node? Did we want to install the CLI? We can specifically set certain settings that would be the same as putting them in settings. Json. That way, whenever we connect to this Dev container, they're already going to be set for us. We can also have default extensions installed. So when working on this app, we're really going to need the C Sharp extension, so we can have it that whenever anyone connects to this Dev container, they're going to have the C Sharp extension installed for them, which seems super useful. We can also go ahead and add even more extensions into this array here. So one extension that our team develops and really likes using is known as the GitHub Pull Request and Issues extension. And we have both a stable and a nightly version, depending if you want the latest fixes or to use it in via Code Insiders. What I can do is right click and say add to Dev container. Json. And then I went ahead and added the ID directly to this array. Now, anytime that we connect to this Dev container, we're going to automatically have these two extensions added to our environment. And then we have some additional properties like we can choose specific numbers for ports to be forwarded for services or parts of our app running. And we even have this cool property known as post create command. And I'm actually going to uncomment it and modify it because this is really helpful because it allows us to automatically run commands once the container is created. So, for instance, here I could go ahead and modify this a little bit to make sure that our net project is properly set up and restored whenever we launch this environment. So I'm going to go ahead and modify it here. There we go. All right. So now that we've gone ahead and inspected our Dev container environment here, what we can do is rebuild our code space. Now, rebuilding it is going to rebuild the back end container, and that's going to make sure these changes take effect. And we're specifically going to have the environment that's designated within this folder here. And so we're not going to be on the kitchen sink anymore. So we won't have just this plethora of software and languages and tools installed, but we're just going to have the ones we need and we're going to have the right version. So, for instance, we wanted. Netcore version 3.1. Now we're going to have that because we set that up in our desk container rather than net version five. So let's go ahead and do it. I can click on the lower left here and I can say rebuild container. Now it's going to recreate the code space and let's go for it. Okay. So we can see that our code space has Reloaded. And now the terminal tells us that we're on a custom image defined in our Dev container. Jason. Okay. And now we can see the C Sharp extension. We need a couple of more assets. I'm going to say yes to make sure we can fully build and run our app. Okay. So I think we should be good to go for running our app. Let's go over to the run and debug view. It nice. So now we can see we have this drop down. We can see that we actually have a configuration to run our app. Let's give it a shot. Open Code Spaces takes care of Port forwarding for us. That way, whenever we have a service running within our app, we don't have to worry about configuring that or finding out the right URL. It's going to automatically be generated correctly through Code Spaces. And here we go. Our application ran and it's just like how we thought it looked like in the picture. So we can see we have our group calling app. I'll close out of that for now. And we can see also if we go over here, we can see the ports that were forwarded, the front end and back end ports, and we can see code faces took care of all of it for us. Stop my app for now. Great. Okay. So now that we have this Dev container environment set up, we want to make sure that we're going to be able to use it anytime we go into this application and anytime that any of our colleagues or just anyone else visiting the repo is able to get into it too. So that way they can quickly get started being productive on this repo. So let's go ahead and contribute it back to the repo. So let's go over to the source control bullet and we can see that any changes that we make to our code are automatically picked up. So let's go ahead and add a commit message. So I'll say add configuration. I can stage my changes and just go ahead and commit them. Very easy and a step Spar. I'll go ahead and push and I could have chosen to push them to a different branch, but I feel pretty confident about these changes. And I also want to make sure that anyone visiting gets them directly on Maine. So I'm going to push them directly to Maine. And it was that easy. So you can see how quick it is to commit directly back to our repo without ever having to leave our editor too. So now I'll just verify those changes did take effect. So I'll say go to repository. You see add configuration. Those files showed up, and I never had to leave my development environment in order to contribute back to the repository. No cloning code locally necessary or anything like that. Now we've seen how quick and easy it is to use code bases to make changes, to create these customized Dev environments, to work with our code directly in the browser and commit changes back to our repository without ever having to leave our editor. But there may be times in which we don't necessarily want to work in the browser, or even beyond that, we don't want to work specifically on a cloud compute. Maybe we need to work locally, or you just prefer to work locally. So we actually have a really cool alternative that we can use this same Dev container set up. So we're still going to have the same customized environment, and we can contribute just as easily back to our repository. But we don't need back in cloud compute, and that experience is known as Vs code remote containers. So let's see how that works. I'm going to open up Vs code in the desktop and I'm going to go over to the extensions bullet, and when I search it up. Here I can search up remote containers and by the extension name here I can see that it allowed me to open any folder or repo inside a Docker container. So the only prerequisite for remote containers is that I have Docker installed and running on my local machine. All the back end compute and everything is going to be coming from my own machine. So let's see how we can contribute back to that same exact environment and run this same app through remote containers on my local machine. So now in vs code locally we can very similarly see we have this remote indicator in the lower left which allows us to again interact with remote commands similarly like we were doing in code bases. When I click on it, I can see that it is essentially our portal into interacting with remote extensions. Because in vs code desktop we have a variety of remote extensions like for working with the Windows subsystem for Linux or WSL or through connecting to different VMs or desktop machines through remote SSH. And we also have a code spaces extension so you can work with your code spaces button desktop via code rather than through a web editor. So with remote containers I have a variety of commands here so I can see I have one. For instance, if I already have source code cloned locally to my machine, I could reopen it in a container I can attach to running containers. Or I could do this thing known as clone repo in container volume. So that's actually the one that I want. If I click on it, I can see that it will allow me to clone any repo from GitHub into a container. Volume volume is essentially just an efficient storage mechanism. That Docker will take care of all of the files and manage them effectively for me. So what I can do is let me go back to the browser and I will find the URL for my repo and just copy it here and I can paste it in. Now we can see that via code has Reloaded and it's going to start up this environment in my desktop. And now we can see that the files have shown up from GitHub and in the lower left rather than saying code faces. Now it reads Dev container and this name csharp.net came from the Dev container Jason because that's the name that we designated in that name property in Dev container JSON. It's doing some final set up and downloads of necessary properties and software and now it's finished. I can go ahead and close out that terminal, just setting things up. So now I'm specifically in this same environment that was set up in code faces, but it's set up on my local machine in this local Dev container. If I wanted to verify that I have the right tool sets, let's make sure I have net. Cool. So this is the version of net that I set up for my Dev container. And if I look open up a local terminal. Do I even have.NET installed on my regular local machine? Looks like I don't. So you can see that Dev containers provide us this really cool way to have these separate environments on our local machine without having to have any sort of cloud based or other sort of back end compute. So within here again, I have full access to my files. I can contribute back to them. I could run my application and since we installed, made sure that we installed that GitHub issues and pull request extension. What we could go ahead and do is see what it actually looks like. Okay, so what I can do is I'll make a change to the README. I'll say update read me and over here, instead of committing directly back to Maine, what I want to do is create a new branch. So I'll call this update README branch. I'll publish this that way. It's actually available on GitHub and it allows me to either push it to my origin or to my upstream. So I'll push it to my origin and then the pull request extension already prompts me if I'd like to create a PR, but not quite yet. I need to commit this change. First I'll say Update read me as the message I can stage and commit and then I need to just go ahead and push this change to my branch. Now that I've pushed the change, I can go ahead and create a new PR. So I'll create the full request and we can see that it prompts me to choose where to merge my changes from so I can merge them from the current branch that I'm working on and where to merge the changes into. So I can merge them either into the upstream or the current repo that I'm working on. I'll just merge them into the current repo that I'm working on and I want to merge them into the main branch. I can choose the title for the PR, so I'll say update README and even a description. It fills out some scaffold, some text for me. I'd say I'd like to update the reading. I could even create it as a draft. I'll say create and I went ahead and created a PR directly within my editor. I didn't even have to leave. And again, this extension works both locally in Vs code in remote containers within code spaces so you can use it within any type of developer flow that you're working on. If I click on this, it'll bring me to the pull request directly within the browser. I can go ahead and add other features and labels that I would typically use, like reviewers and assignees and milestones. And I can merge the PR directly here. I can also go ahead and open up a different view and do things like add comments. I like this change and I could start a whole review or just add a singular comment. So let's go ahead and merge the PR for some final clean up. I'll go ahead and delete the branches that I just created. It's a very smooth and a great interlook workflow for doing your source control flows directly with envious code without ever having to leave your editor. So thank you so much for joining me for this session on Code Spaces and Dev containers and the Remote Containers Extension Visual Studio code. I wanted to provide you some final resources where you can learn more and you can connect with our team further if you have any questions or feedback. So one really great resource is the Code Spaces discussion board. So if you go here and you can provide some feedback to the Code Spaces team, or you can ask any questions. So if you try out Code Spaces or as you're anticipating trying it out, you can post any discussions here on the feedback board. You can also see what other folks are talking about and see if any questions or feedback you may have is already being discussed. So a great way to connect with the team. There. Another good resource is this VSCode. Devcontainersrebo. And so these are going to be the definitions that are used within both Code spaces and in the Remote Containers extension. So when we did that, add Development container configuration files. That's the command that's both available within code spaces and available within remote containers because like we saw, the same Dev containers are compatible across both environments. So the definitions can be found within this repo. So in here we can say containers and then we can see all the different container definitions that are here and we can learn even more about them. So for instance, if we wanted to learn more about let's say net and SQL definition, we can learn here who are the contributors to the definition and more about the definition type and how to use it and all those kinds of things. And we can see that there are even issues and pull requests here. So if you'd like to go ahead and try contributing back to a definition or contribute your own definition completely, you can totally do that here. Another great resource that we have is this Beginner's video series to Dev containers. So it can really give you the fundamentals of working with Dev containers and what are the different parts and how to create your own and customize them and things like that. So it's an eight part video series and myself, one of my colleagues walks you through all the different parts and so it's a useful series for both Code Faces and the Remote Containers extension. And then another resource pivoting a little bit more towards the Visual Studio Code and Remote Container side of things is that we do have the Ascot docs where you can learn all about remote development, including the remote containers extension and tutorials and some more Dev containers tips and tricks and those Dev containers tips and tricks will be applicable to code spaces as well. And then finally as you try out remote containers specifically the pivoting again specifically to the remote containers experience in Vs code, you can provide us any sort of issues, questions, feedbacks, bug reports, anything like that within this Vs code remote release repo and that is available on GitHub. You can also see any sort of feature work that we're planning anything like that coming up in the open in our iteration plans that we have in issues available on the repo and there are also great code spaces specific docs as well available on Docs GitHub.com where you can learn all about the specifics of code spaces, working with them, creating them and go through tutorials, helpful videos and helpful quick starts. I've also gone ahead and included that same set of links and resources on this side here so you can reference them later along with my full name and my Twitter handle so you can go ahead and connect with me or let me know if you have any sort of questions or feedback as you try out these experiences. Thank you again so much for joining the session and as always Happy coding. Hey it's Joe Eames with Ng. Comp if you liked that video be sure to click subscribe either here somewhere and if you're looking for something more here's another video for you watch here or there or somewhere.