In this next lesson, we're going to take a look at continuous delivery or CI CD.
And we're going to make a couple of changes.
One of them I've noticed here a fairly obvious change inside here I've got the order item here times
three and it equals 200, which in my mind that should say 600 because we want to multiply it by three
of course.
So a simple fix that's going to be fairly obvious that it's been updated when we come to take a look
at this order after we've published our updated code.
Another fix that I just want to take a look at, although not a fix as such, is just to invalidate
the cache.
When we go to the orders and we see that we've got or we had a payment failed and then we updated to
a payment received, we want to invalidate the cache when we create a new order as well, so that we
always get the updated versions of this if a new order has been created.
So we don't just retrieve the orders from cache.
So a couple of very simple fixes that we're going to make to our application.
We'll do those now and then we'll take a look at continuous integration.
So back in our code let's first of all open up the order detailed page.
And inside here where we've got the table cell we've got the X here for the item quantity then the currency
format here.
This should be the item price multiplied by the item quantity.
And that will fix that problem.
But we need to get this change up to Azure of course.
Because that's not going to affect our published application until we do that.
Another very small quick change I'm going to make is in our order API.
When we do create a new order, then I would like to invalidate the cache for the fetch orders so that
we see the updated order in that list.
Now, we've seen this kind of thing before.
We've done this kind of thing before.
We're going to specify tag types and in square brackets in quotes I'm going to say orders as the tag
type.
And then for our fetch orders query we're going to specify, we'll add a comma and then say provides
tags.
And in square brackets we're going to specify orders.
And then in our create order method just below the query we're going to use the on query started method.
We'll make it async open parentheses and curly brackets.
And in fact we don't need a parameter for the first one.
So I'll just specify underscore comma.
And then in the second parameter we use dispatch and query fulfilled.
And at the arrow open curly brackets.
And we'll just use we'll keep it really simple here.
We'll just say await query fulfilled.
And then we'll dispatch the order API dot util.
And we'll just use the invalidate tags and in parentheses then square brackets.
We'll specify orders.
So super simple changes, and they both should be fairly obvious when we have deployed our application.
So now let's take a look at continuous integration.
And if we go across to well first of all we'll go to GitHub and where we've deployed our application
code.
And if we go to the actions then what we can supply to GitHub is GitHub actions.
And we can create a workflow effectively so that when something happens to our GitHub repository, we
push a new updated commit into GitHub for instance.
Then we can automatically kick off a workflow that's going to build our application, creates a published
version of Our.net application, and then deploy it to Azure, taking care of all of the security of
logging into Azure, making sure we're authenticated, and all of that can happen in the background
once we have committed our latest changes to GitHub.
So we'll go back to Azure because Azure can help us out with this.
And if I go to Azure and we want to go to our app service for this.
So I'm going to click on Restore Course.
And if we go to in the settings on the left we want to go to Deployment Center.
And inside here we can select a code source in our settings.
And we're using GitHub.
There are other options of course but the fuller demonstrations I've been using GitHub.
So that's what I will be using.
I'm already signed in via GitHub to Azure, so I've automatically got the accounts that I use for GitHub.
Here we can select the organization and then we can select the repository we wish to use with this and
the repository that we wish to use.
And we'll have to find it in the list.
In my case it's restore V2.
And I'm just going to use the main branch for this.
So when we deploy something to the main branch then it's going to automatically publish this to Azure.
The build the runtime stack is dotnet.
Of course the version.
Version nine.
Obviously if you're in the future and it's dot net ten, great.
Whatever it is, that's fine.
Then we select how we want our GitHub action workflow to authenticate to Azure.
If you choose user assigned identity, the identity selected will be federated with GitHub as an authorized
client and given write permissions to the app.
So that's the one that we'll use.
And then the Azure subscription for the identity.
We will select create New.
And effectively Azure is going to create an identity specifically for authenticating our workflow to
Azure.
So we can leave that as create new.
If I look in this list I've got various identities being created for different projects on here that
gets created automatically for us as long as we leave that selected to create new.
And this is going to create a workflow configuration file for us.
So if I click on preview file.
Then this is what it's going to create in our GitHub.
Now notice the path.
It's going to be in a path called GitHub workflows.
Main underscore restore course dot YAML.
And inside here is the workflow itself.
What this will do.
It's got a name build and deploy etc. but on push to the main branch.
And this workflow dispatch means that we can also run this workflow manually on demand.
It's got a job inside here and it runs on windows latest.
GitHub is going to start a virtual server to run our workflows.
So it uses a windows server effectively in the background.
And then it goes through a number of steps.
It first of all checks out our code.
It sets up dotnet core with the correct version.
It then runs a build of our application.
It then publishes our application or runs the publish command, just as we did manually when we did
this ourselves and outputs it to a directory called My App.
And then it uploads artifacts and then we deploy it to Azure.
And what this does is it uses secrets from GitHub that this is going to supply to GitHub directly.
We don't need to configure GitHub with anything.
Azure is going to take care of this for us with the identification the user identity is creating over
here.
And then it's going to deploy it to our app so we can close this.
This is just a preview of the file that it is going to create.
So I'll click close.
And then all we need to do then is just save.
And this is going to deploy something to GitHub.
So I'll click save.
And this will set up the deployment.
And great.
Now that's successfully set up.
If we go back to GitHub and let's just go back to our code and then go to actions, what we find is
that we've got a workflow running.
Now this may or may not work.
Let's go and take a look inside here.
We've got two steps in here the build step and the deploy step.
If we go and take a look at the build step, then it's running actions, checkouts, etc. and this is
going to take a moment or two.
Now this is not going to deploy our changes because we didn't commit them to GitHub yet from our local
machine.
So I'm just going to pause the video and see how this gets on and come back when something significant
has happened.
Okay.
It certainly seems it got further than it did in testing.
So that's a good start.
And if I click on the deploy step then we'll go through the logs inside this one.
Once again I just want to make sure this happens successfully.
So I'll just keep an eye on these logs as well because this part is making me slightly nervous.
And I'll come back once something significant has happened here.
Okay.
That's good.
Whatever bug there was in place with the workflow previously, looks like it has been resolved now,
and without making any changes to the workflow configuration file that Azure provided, the deployment
did take place successfully, but it hasn't done anything to our application because nothing changed
in our application for the commits that Azure was working with.
Because Azure is working from our code, and if we take a look at our commits, then we've got a commit.
But this one is committed by Azure.
And if we take a look at this commit we've got our pre publish here.
And if we take a look at this commit the changes inside here.
The only change is the workflow.
It doesn't include our code changes that we've made locally on our developer machine.
So we've got a bit of work to do.
And what I'd also like to happen is it also builds our react application at the same time, so that
we don't have to do that step manually ourselves.
Not that that's a big significant step, but it is very easy to forget.
And if we have our workflow building our react application, it's just one more thing that we don't
need to think about.
And we're going to take a look at customizing this workflow and actually deploying our updated code
in the next lesson.