>> Looking for a fast and easy way to set
up some continuous integration and deployment.
Well, look no further than GitHub Actions,
which is here to save the day and Visual Studio.
So come on down and learn more on
this episode of Visual Studio Toolbox.
[MUSIC].
>> Hey everyone, welcome to
another episode of Visual Studio Toolbox.
I'm your host Leslie Richardson,
and today we're going to be talking about GitHub Actions.
Joining me today to talk all about them is Senior Program Manager,
Angelos Petropoulos. Welcome Angelos.
>> Hello. Good to be here.
>> Nice to have you. Can you tell me more
about yourself and what exactly GitHub Actions even are.
Is that related to
the GitHub version control things that I use on
a regular basis in Visual Studio?
>> Yeah, it is. I'm a PM for .NET.
The last few years I've been working on
to link for web projects in Visual Studio,
so I look after features like publish.
What I'm going to show you today is,
like you said, GitHub Actions.
You might tell from the name, it gives it away.
It's GitHub only feature right now,
but the idea is that you can do
CI/CD through a workflow defined in GitHub.
If your project is hosted on GitHub,
Visual Studio can help you set it up
through right-click publish, which I'm going to show you today.
>> For people who don't know what is CI/CD.
>> If you have a piece of code and you have
an application that you want to deploy somewhere.
One way to do it is you can right-click
on your project in Visual Studio,
publish it, Visual Studio helps you build it.
Takes everything that you have on your local machine,
configures it correctly and push it on your deployment target,
which is great and very convenient.
We have a whole bunch of users during that,
about 3-400,000 a month actually.
The alternative is if you
want your deployment to happen from source control,
so instead of deploying what's exactly on
your local machine but you want
something that goes out of source control,
something that maybe has already run some tests,
maybe as part of it building it does some other checks.
That's what we call continuous integration, continuous deployment.
You can't do one without the other,
so you could just do continuous integration and just
build your project every time you check
in make sure your test pass.
When you're ready you can tack onto it,
CD, the continuous deployment.
After your test pass,
you can also automatically deploy it to your server.
As you're checking in code and going about your development,
your production environment or your testing environment is always
up-to-date without you having
explicitly to do the publish every time.
>> Awesome. That's where GitHub Actions can come
in and make that CI/CD or continuous integration,
continuous deployment experience better, right?
>> Exactly. That's the option that you have when
your code is source controlled in GitHub,
but it also supports other things.
You can have your source control in other places as well.
But what we're going to show today is that simple scenario.
Your code is on GitHub,
they're using Visual Studio and we make it
really easy for you to be able to just
configure CI/CD for your project in
just a few seconds as you can see. A few minutes Leslie.
>> Cool. Well, we like easy on the show,
so yeah, definitely I'd love to see how it works.
>> What I've got here is the latest preview of Visual Studio,
at the time of this recording is 16.10,
but the feature that I'm going to show you
exist ever since 16.8 preview three.
You just have to make sure for
all the bills that it's enabled under
tools options is called GitHub Actions support for publish.
What I have here is just the latest preview.
I spared you having to watch me do a found new project,
ASP.NET Core, that's all I've done here.
The other thing I've done is I've gone ahead and post to GitHub,
so you can see that Solution Explorer
tells me that this project is source controlled.
Like I said, what I'm going to show you is I'm going to
right-click and ask to publish this project.
Now, it's the first time I'm doing it for this project,
so I'm being asked,
where would I like to publish today?
In publish, I'm proud to say we support many destinations.
What I'm about to show you will eventually
work for most of the destinations that publish supports,
which just right now in preview,
we don't have support for,
let's say, an on-prem FTP server.
We don't have support for GitHub Actions
when you publish into a folder,
but we do have support for
GitHub Actions when you publish into Azure.
I'll show you that, I'll pick Azure as my target.
On the next screen, Visual Studio is
aware of the type of project that I'm publishing, it's ASP.NET.
It knows what targets in Azure are
applicable for this project type, shows me the list.
Let's say I want to deploy this to Azure App Service on Linux,
that's a target we support GitHub Actions for, click "Next".
Now, here Visual Studio is helping me
pick the instance I want to deploy to.
It's going through the last subscription I used,
and it's showing me all the instances that already exist.
I can always click the ''Plus'' button and
provisioning new instance if that's what I wish to do,
just going to save myself some time
and pick an existing instance that I've created before.
Now, that I click "Next",
the first thing that you're
going to see by having this preview feature in your build,
Visual Studio is smart enough to know that the options I've
picked can be fulfilled either by using just the normal publish.
I built everything in BS,
just click the ''Publish'' button and deploy.
Or I have the option of doing CI/CD,
that's why we present you the screen.
The first option is what you're aware of,
what you are always used to.
Right-click publish generates a pubxml file
or a publish profile, as we like to call it.
There is a big ''Publish'' button,
you click it and it does a deployment.
Or you can see this new option,
which is doing CI/CD through GitHub Actions.
Clicking "Finish" here, Visual Studio is going to create
a working workflow that is applicable to my project.
I'll go ahead and do that.
What's happening here is Visual Studio knows exactly how to
make this project work in the options that I have picked.
It's using an API to get access to the most appropriate template,
the most appropriate workflow
file that it can possibly can come up with,
so that it's a no hands,
no edit experience to get it to work.
That was pretty quick, but at the top
here I'm going to walk you through the UI.
We have a new file generated.
It's the name of my project.yaml, just a default name.
It's telling me that the deployment target
is Azure App Service on Linux.
There's a little watermark on
the right-hand side telling me this is
doing CI/CD using GitHub Actions.
>> Nice.
>> I have a little status here telling
me what is happening right now and what do I need to do next.
This is letting me know that the workflow will not
run until I commit and push to the GitHub repo.
This is the first thing that is different
from traditional right-click publish.
Usually I have a big button,
I can click on it and on my command it can perform the deployment.
Here because it's CI/CD,
I have to kick it off via trigger.
Now, this template, this workflow that we've created,
it's so ready to go.
I'm just going to go ahead and click this and have it
running in the background while I talk to the rest of the screen.
I'm going to click "Commit" and push here.
This is doing its thing, it provision the workflow.
Now Visual Studio knows exactly the type of project that
I have open and the target that I picked in Azure.
It's downloading the best template,
the best GitHub Action workflow file it can find.
To make sure that with virtually no touch,
I can get my application deployed to Azure through CI/CD.
I'm going to take it from the top
of the screen, working downwards.
At the top of the page, I have a new workflow file created,
it's named after my project.yaml.
It's telling me it's being deployed to Azure App Service on Linux.
On the right-hand side is reminding me that this is
using CI/CD GitHub Actions.
This is typically what the big ''Publish'' button is.
>> Is the end game to be able to have
multiple options for CI/CD in addition to GitHub Actions?
>> We're definitely considering support for Azure DevOps,
and we're looking really closely to
the ability if you have one convert to the other.
We know we have a whole bunch of customers who have
Azure DevOps pipelines that
they're playing around with GitHub Actions,
so we're considering giving them a little converter.
>> That's cool.
>> But what we would love to hear from people
if they need support for something
specifically or a conversion for
something specifically we would love to know,
helps build our case for it.
We've created the workflow.
I have my status here of what's
happening right now and what I need to do next.
It's telling me that the workflow will not run
until I commit and push
the workflow and the changes to my GitHub repo.
This is a little bit different than
publish because now we're using CI/CD.
It's going to happen on the trigger that we did,
aspect, which in the section below it's telling you it's on push.
Every time we push a change to the repo, this workflow will run.
Let me click "Commit and push",
let it run in the background,
and I'll walk you through the rest of the screen.
The workflow is being provisioned,
which means that Visual Studio is
making all the necessary connections between Azure, the repo,
downloading any secrets, putting in the right place,
making sure that workflow actually exists on the repo,
and then it's going to start monitoring for its execution.
Actually, it goes fast enough to start
monitoring immediately, and it's telling me it's running.
>> Awesome.
>> Yeah, I love this.
I just click a button, and I just do nothing.
>> Right? Let the magic happen.
>> While this is happening, it's
a perfect segue for me to explain why it's executing.
It's executing because the most common trigger is on push,
another trigger is on the PR,
maybe on a merge, which in Visual Studio,
we start with the simplest one.
The section below, it's giving you
a little summary of how the current workflow is configured.
It's also telling you that it required a published secret.
Because the CI/CD is going to
take our application and put it in Azure,
the CI/CD operation, the
execution of the build and deployment is happening on GitHub.
Now, GitHub needs to have access to the instance,
so we need to give it, somehow,
access to the credentials,
and we don't want any of that to be
anywhere near source code or
anywhere where it can accidentally leak.
The best way to do that is to configure
it through a GitHub secret on the GitHub repo itself,
and Visual Studio has done that,
and it's telling you that the secret
has been found in the repository.
>> It did all that work for me.
I didn't have to manually create the secret.
>> Exactly.
>> Awesome.
>> Exactly. Here's what it did.
It basically went to the instance in Azure and said,
"What are the conditions that I need
to download the published profile?"
It then went to the GitHub repo.
It created a secret with the name that you're seeing here.
It put the contents
of the published credentials encrypted into the secret,
and then in the YAML file,
in the workflow itself,
it has told it to go and create
the deployment action and use this publish profile
when it's doing the deployment. All of that was done for me.
>> Awesome.
>> Now, if I want to,
I can click "Edit workflow".
This will drop us into
the YAML editing experience in Visual Studio.
This is literally the template of Visual Studio
downloaded based on my selections in the wizard.
It's the one that when I click "Commit and
Push" was sent to the repo and was executing.
I can make changes here.
We will, in Visual Studio, respect the changes.
I know that people often
worry if something's automatically generated,
"If I mess with it, will it just jump over my changes later?"
That is not the case.
We are generating this file,
but that's because you told us,
to the wizard, that you want to do in your deployment.
From that point onwards,
we will respect any changes you make to the file and in fact,
we expect you to build it up over time.
Feel safe, that this is actually reliable,
and it's not going to lose any changes you may not do.
But maybe we don't yet expose to the summary screen.
We do have plans to give you
some rich UI controls to be able to
change some of the settings without leaving the screen,
but right now, if you wanted to change
the SDK version of the configuration,
we'll drop it to the YAML file to reinforce that.
You can absolutely make changes here, and that's absolutely fine.
Then finally, we have our hosting section.
This is giving me information about
the instance in Azure I picked to deploy to.
It's giving me things like the
resource group and the resource name,
subscription GUI, then the add link to the site.
Now, I'm going to go back to the top. That was pretty quick.
My workflow was running in
the background as I was explaining all this.
It tells me it completed successfully.
If I'm curious, I can download
the workflow logs and view them inside of Visual Studio.
If not, I can go "Open in GitHub",
go and check out the execution on the GitHub site.
This was a deep link into my repo
and also a deep link into the Actions tab.
I only have one action currently
for this repo because I've only done this once, build and deploy.
I can click on it, and it will give me
the detailed log of what was
happening while Visual Studio was telling me it was executing.
>> Awesome. If we were on this site while
the workflow is being, what's the word?
Prioritized or created, then we
would've been able to see all the checks get
checked off one by one, right?
>> Yeah. It was actually pretty quick.
Usually, when I give this demo,
I have enough time to come back here and see some
of them through [inaudible].
This was super-quick, both in VS and here.
I guess it'll be cool if we just expand one of the steps.
This is the deployed to Azure Web App step.
We can get a bit of a description of what it did.
It even has a handy link to the app service URL we deployed it to.
Let's click on it and see what happens, right?
>> Yeah. This is good.
>> This was my application deployed into Azure using CI/CD,
and all I did was right-click "Publish",
answer some questions, and then said, "Okay." Thank you very much.
>> Awesome. As simple as that.
>> As simple as that.
It goes without telling now
that every time I go in and make a change,
if I go to set up a CS, and I make a change,
and the next time I push,
the exact same thing is going to happen.
The workflow will run,
and if I go back and refresh my page,
I should be able to see my pages and
my changes without having to constantly right-click "Publish".
>> What a time-saver.
>> Exactly.
>> That's really great.
Moving forward, what's next for GitHub Actions?
>> A couple of things. Let me go back to the Summary screen.
The plan for GitHub Actions is to help you configure
more settings to the summary page
without having to drop into the YAML.
Support more project types.
As we move forward, we want to
support pretty much everything in .NET.
Support more deployment targets.
I said that we don't support IIS or FTP,
some other things right now,
we want going to add more support for that.
We're seriously looking into a conversion from
Azure DevOps Pipelines to GitHub Actions workflows.
I would love to hear more from customers if
they're really interested in that.
We're really interested in there.
>> Great. If people do
want to share their feedback, where can they go?
>> Best place is develop a community because that way,
we can aggregate things,
we can answer questions publicly, and we can have a dialogue.
You can always tweet at me or e-mail me at angelpe@Microsoft.com.
I would love to just have a personal conversation on that as well.
>> Good stuff. Well, thank you for sharing all that.
I think that is
a really fast and easy way to set up some good CI/CD,
which a lot of teams are doing these days, so that's really cool.
Thanks for being here, and I'm looking forward to see
where we go from here with GitHub Actions and beyond.
Until next time, happy coding, you-all.
[MUSIC]