Hey friends, you know there's a saying
that friends don't let friends right
click deploy. Now, I do occasionally
right click deploy, but Azure's got
multiple services that help you
deploy your application automatically
and safely and Barry is going to
show me how, today on Azure Friday.
Hey friends, I'm Scott Hanselman.
It's Azure Friday.
I'm here with Azure Barry.
Always loving how you break down
information and deployment is another one.
There's multiple ways to deploy stuff on
Azure and sometimes I just right click
and deploy which can be a great option.
It's just not a sustainable option if you
have to deploy on the regular, isn't it?
Yeah, that's what it is.
You can do that,
but it's just not sustainable and on
the long run it will cause more trouble
and cost more time and money than if
you actually set up a system for it.
OK, so I've heard that that we can
you get deploys an we can use GitHub
actions and we can use Azure DevOps
and we can use third party services.
We can do zip deploys.
There's a lot of ways to deploy
things on Azure. Yeah, but I'll just.
I'll keep it very simple.
OK, there is.
There are just a couple of services
that you could or should use and
waste that you should use to
deploy your application to Azure.
And in this episode I'm just going to
try and help you decide which ones
that you should use for which scenario.
Alright, let's do it.
So before we dive into the
services that you can use to deploy
your application to Azure,
let me just share some context
of what we're actually talking
about and that is continuous
integration and continuous delivery.
So within continuous integration you have
developers and also operations people.
Hopefully they're working together
in some sort of a DevOps way.
They're all making stuff so
developers make code for applications
and hopefully operations.
People also make infrastructure
echo S code or arm templates.
Things like that,
and they then check that in
into source control,
which could be GitHub for instance,
or Azure repo.
And when they do that,
hopefully also on a regular basis,
then the build pipeline that would end.
Activate and that thing.
What that does is it would take
the code from the source control.
It would then built it so compile the code.
Maybe also run some tests on it,
some unit tests or some other tests,
and if that all goes well then would
take the package so the resulting package,
which could could then be an application.
But also some infrastructure
aren't effects like ARM templates,
so an updated infrastructure.
Let's say it takes that it then
gives that to the release pipeline
and a release pipeline then.
Creates or updates infrastructure with,
let's say the ARM templates.
It will then deploy your application
to the new and updated infrastructure
and we then run tests as well.
Maybe more unit tests or other tests
may be functional tests as well and
this would also then be the place
where attests people would then
do a manual test and potentially
also sign off on the release.
Do release approval if you
configure it that way and
then from there it would then
be released to production.
Which means your applications actually
in production and then from there users
can start the user new version of your
application and able to tell what they
think to product management. You know?
Maybe they report some bugs or maybe they
have some ideas about the application.
Maybe they want some new features.
Product management collects
all that information,
creates requirements and stories for
the teams of developers and operations,
and so the cycle continues on with continuous
integration and continuous delivery.
Now.
The build pipeline in continuous
delivery is an automated thing.
This thing runs whenever you check
in code into source control and then
when you call it continuous delivery.
The release pipeline is actually
something that you do on demand,
so you would have your completed
build off your application and also
your infrastructure artifacts and
you would then press a button to
release all of that to production
and then the new ones here is when
you call it continuous deployment
which is slightly different.
Then again, the build pipeline is automated,
but then also the release
pipeline is automated,
which means as soon as you check
something into source control,
it basically gets deployed
all the way to production.
So that's a little bit of context
for what CI and CD actually means.
Now within Azure you have multiple
options to deploy stuff to Azure O.
Why would you actually do all of
that and set up a CI and CD process?
You would do that to get higher
quality applications.
So when you do that,
the process is actually automated,
which means that you don't
deploy manually anymore.
Reading steps from a script,
and therefore you have less errors
and higher quality software.
Also you can deliver faster because
now you don't have so many manual
steps and other many people involved,
which means you can just deploy faster
and also automated costs are also
lower because there are less people
involved and the quality is higher,
so you don't need to solve as many bugs.
And finally you have more flexibility.
Which means that you can change your
application quicker to adhere to
whatever the users actually want.
So you could create features
and deploy those within a week
instead of having complete.
Deployment weekends,
which can take a long time.
Now within Azure you have lots of options
to actually deploy your code to Azure.
Now,
like Scott alluded to,
you could use in Visual Studio
or even Visual Studio code.
You could right click publish,
which is a way to do it,
which you get your code actually into Azure,
so you can do that,
but it's not repeatable because that means
that the profile of actually doing that,
the information of how your computer
deployes that thing to Azure
is only on your local computer.
And then when somebody else does that,
it is slightly different
and you wanted to always be
the same, because when it's slightly
different and then the application
does something different or.
An error or curves or something you
don't exactly know why that is,
so it's not that repeatable,
and it's also not automated there,
and it doesn't really work well
when you work with multiple people.
So then what do you do?
What are your alternatives?
Well, you could choose Azure
DevOps as an alternative.
Azure DevOps is an application
lifecycle management suite.
There's multiple services that you can
use to store your code in and also to
create build pipelines and release pipelines.
You could also use.
Visual Studio App Center,
which kind of does the same
attend for mobile applications?
Then there's also Azure DevOps
starter which is an Azure portal
experience that helps you to set
up pipelines within Azure DevOps.
And then finally there's also GitHub
actions which is kind of a lightweight
application lifecycle management suite
but then located within GitHub itself.
So you could use GitHub action
to deploy your code from the
code that is stored in GitHub.
So how do you choose between these services?
What should you use?
Well,
I didn't ask this question and
that's a very simple question.
What type of app do you want to deploy?
And then once you've answered that,
you could take a look at the
functionality of these different
services to see if they fit your needs.
Now let's take a look at that question.
What type of application
do you want to deploy?
Is that a mobile application?
And that's kind of simple,
because then you would use Visual Studio
app Center which is specialized in
testing deploying mobile applications.
If it is anything else,
then you can use all of these other
services as well as your DevOps Azure
DevOps starter and also GitHub actions.
So let's first look at the Azure
Dev OPS starter to give you some
context of what that actually is here.
In the Azure portal I can start
to create a resource and then I
can say Dev OPS starter and then
it would pop up the wizard.
Like I said,
that is an Azure portal helper
experience that helps you to set up
pipelines within Azure DevOps so it
doesn't actually provide you with
the pipeline right here in Azure,
but it set something up in Azure
DevOps and this is a very.
Easy way to get started.
So first of all it will ask you what
type of application do you have and
this can be anything really.net,
node, JS, Python, go Ruby.
See what have you.
From thereiselected.net,
now I can selectwhattypeof.net
application do we want to deploy
that asp.netasp.net core?
Maybe some IoT thing and maybe
you also have a database there
and then it will ask me where do
you want to deploy this too?
Is that to an app service web app to
an Azure function virtual machine?
Or maybe something else as well?
Let's just say web app for this sick
and then I can create a web here or
select one here to deploy it to.
And once I do it then creates.
A release and build pipeline
within Azure DevOps that I can use
and that looks like this.
This here is the Azure DevOps portal.
This is one of my projects
that I use and we're looking at
one of the build pipelines,
so all of these steps that you
see here actually compile my code
and make it into a package that
I can then use to deploy to my
Azure Web sites to my Azure App
Services Web app in my case.
Which is very cool.
This gets triggered automatically
when I check in my source code.
So whenever I do that,
this whole process starts to run and
then afterwards my release pipeline
starts to run and that is this one.
Let's take a look at what
the steps are in this one.
So this consists out of actually getting
the package receiving the package,
which is the application in this case
and then following these steps here,
which in my case is deploying some
of it to an Azure function and
then also deploying the application
to an app server slot and then
later on swapping that slot with
the actual production slot.
So this is very flexible because I
can create lots of steps here and
those are all predefined steps that
you can just use out of the box.
Like deploying to an app servers for
instance also to a database and lots of
other things like 2 containers as well,
which means that you just drag
and drop these things into your
pipeline and then you just configure
those to make them work for you,
which is very cool.
Now that's a bit of the functionality of the
Azure DevOps starter and also Azure DevOps.
Now let's put this next to each other and
help you choose between all of the services.
So we've had Azure DevOps absent
are Visual Studio app center Azure,
DevOps starter, and also GitHub actions.
Now, if you want to build so compile
source code then you can use Azure DevOps.
Also Visual Studio app centered and for
mobile applications and also GitHub actions.
It does kind of the same there.
If you want to test your applications
as well, so for instance,
running unit tests or other types
of tests within your build process,
or maybe within your release process,
then also you could use these same
services for that they do that as well
if you want to deploy your application
or guess what all of these services
can do that as well so they're all
built and also deployment services.
And they can also test your application
if you want to create and build,
create, build and release pipelines.
So not actually.
Run them or have them,
but just create them.
Then you would use all of these services
including the death of starter which
we just saw that is meant to create
those pipelines within Azure DevOps.
And then if you want to store and share
source code like in GitHub for instance,
then you could choose GitHub actions
as that is tide to GitHub basically.
So that works.
But also Azure DevOps has a service for
that which is actually called Azure Repose,
which you can use as a git
repository to store your code in.
If you want to manage a work backlog so
items that your team needs to work on,
then you could choose Azure DevOps
which has a great solution for
that and also GitHub actions,
again because GitHub also
has GitHub issues and now.
A bit more advanced features as
well that can help you with that,
and if you want to manage mobile
application lifecycles then you would
choose Visual Studio App Center because
it's specialized indent and then with
that I hope that this helps you to
choose between the options that you can
use to deploy your application to Azure.
Once again,
extremely clear and thoughtful
way to do things,
and I actually mix and match myself as well.
I do have a number of different
sites that are using Azure DevOps.
I found that visual pipeline to be really
easy and then I ended up converting
that into YAML and then you know for
smaller things I use GitHub actions.
You lay that out in a very,
very clean and organized way there,
and folks can check you out online
on your blog on your courses.
Thank you so much for explaining
deployment today on Azure Friday.
Hey, thanks for watching this
episode of Azure Friday.
Now I need you to like it.
Comment on it.
Tell your friends, retweet it.
Watch more as your Friday.