WEBVTT 00:00.140 --> 00:04.370 In this next lesson, we're going to take a look at continuous delivery or CI CD. 00:04.700 --> 00:07.070 And we're going to make a couple of changes. 00:07.070 --> 00:14.810 One of them I've noticed here a fairly obvious change inside here I've got the order item here times 00:14.810 --> 00:22.340 three and it equals 200, which in my mind that should say 600 because we want to multiply it by three 00:22.370 --> 00:22.970 of course. 00:22.970 --> 00:29.090 So a simple fix that's going to be fairly obvious that it's been updated when we come to take a look 00:29.120 --> 00:32.870 at this order after we've published our updated code. 00:32.900 --> 00:38.240 Another fix that I just want to take a look at, although not a fix as such, is just to invalidate 00:38.240 --> 00:39.260 the cache. 00:39.350 --> 00:47.990 When we go to the orders and we see that we've got or we had a payment failed and then we updated to 00:48.020 --> 00:53.510 a payment received, we want to invalidate the cache when we create a new order as well, so that we 00:53.510 --> 00:59.390 always get the updated versions of this if a new order has been created. 00:59.390 --> 01:01.640 So we don't just retrieve the orders from cache. 01:01.640 --> 01:05.590 So a couple of very simple fixes that we're going to make to our application. 01:05.620 --> 01:09.580 We'll do those now and then we'll take a look at continuous integration. 01:09.580 --> 01:15.250 So back in our code let's first of all open up the order detailed page. 01:15.250 --> 01:24.040 And inside here where we've got the table cell we've got the X here for the item quantity then the currency 01:24.040 --> 01:24.640 format here. 01:24.640 --> 01:30.220 This should be the item price multiplied by the item quantity. 01:30.490 --> 01:32.860 And that will fix that problem. 01:32.860 --> 01:35.920 But we need to get this change up to Azure of course. 01:35.920 --> 01:41.320 Because that's not going to affect our published application until we do that. 01:41.350 --> 01:45.670 Another very small quick change I'm going to make is in our order API. 01:45.700 --> 01:53.110 When we do create a new order, then I would like to invalidate the cache for the fetch orders so that 01:53.110 --> 01:55.810 we see the updated order in that list. 01:55.930 --> 01:57.820 Now, we've seen this kind of thing before. 01:57.820 --> 01:59.350 We've done this kind of thing before. 01:59.350 --> 02:06.400 We're going to specify tag types and in square brackets in quotes I'm going to say orders as the tag 02:06.430 --> 02:07.000 type. 02:07.000 --> 02:13.890 And then for our fetch orders query we're going to specify, we'll add a comma and then say provides 02:13.890 --> 02:14.760 tags. 02:14.760 --> 02:18.390 And in square brackets we're going to specify orders. 02:18.390 --> 02:26.400 And then in our create order method just below the query we're going to use the on query started method. 02:27.510 --> 02:32.010 We'll make it async open parentheses and curly brackets. 02:32.010 --> 02:34.890 And in fact we don't need a parameter for the first one. 02:34.890 --> 02:36.990 So I'll just specify underscore comma. 02:37.020 --> 02:44.940 And then in the second parameter we use dispatch and query fulfilled. 02:48.180 --> 02:51.480 And at the arrow open curly brackets. 02:51.480 --> 02:53.790 And we'll just use we'll keep it really simple here. 02:53.790 --> 02:55.800 We'll just say await query fulfilled. 02:55.800 --> 03:01.620 And then we'll dispatch the order API dot util. 03:01.740 --> 03:07.380 And we'll just use the invalidate tags and in parentheses then square brackets. 03:07.380 --> 03:09.120 We'll specify orders. 03:09.300 --> 03:17.170 So super simple changes, and they both should be fairly obvious when we have deployed our application. 03:17.200 --> 03:20.590 So now let's take a look at continuous integration. 03:20.590 --> 03:28.120 And if we go across to well first of all we'll go to GitHub and where we've deployed our application 03:28.120 --> 03:28.540 code. 03:28.540 --> 03:34.780 And if we go to the actions then what we can supply to GitHub is GitHub actions. 03:34.780 --> 03:42.130 And we can create a workflow effectively so that when something happens to our GitHub repository, we 03:42.130 --> 03:46.480 push a new updated commit into GitHub for instance. 03:46.480 --> 03:52.840 Then we can automatically kick off a workflow that's going to build our application, creates a published 03:52.840 --> 04:00.100 version of Our.net application, and then deploy it to Azure, taking care of all of the security of 04:00.100 --> 04:06.130 logging into Azure, making sure we're authenticated, and all of that can happen in the background 04:06.130 --> 04:10.210 once we have committed our latest changes to GitHub. 04:10.930 --> 04:15.140 So we'll go back to Azure because Azure can help us out with this. 04:15.140 --> 04:21.890 And if I go to Azure and we want to go to our app service for this. 04:21.920 --> 04:24.530 So I'm going to click on Restore Course. 04:24.710 --> 04:30.470 And if we go to in the settings on the left we want to go to Deployment Center. 04:31.040 --> 04:37.250 And inside here we can select a code source in our settings. 04:37.250 --> 04:38.960 And we're using GitHub. 04:38.990 --> 04:43.670 There are other options of course but the fuller demonstrations I've been using GitHub. 04:43.670 --> 04:45.770 So that's what I will be using. 04:45.890 --> 04:53.240 I'm already signed in via GitHub to Azure, so I've automatically got the accounts that I use for GitHub. 04:53.240 --> 05:00.290 Here we can select the organization and then we can select the repository we wish to use with this and 05:00.290 --> 05:03.200 the repository that we wish to use. 05:03.200 --> 05:05.990 And we'll have to find it in the list. 05:05.990 --> 05:09.050 In my case it's restore V2. 05:09.050 --> 05:13.220 And I'm just going to use the main branch for this. 05:13.220 --> 05:20.910 So when we deploy something to the main branch then it's going to automatically publish this to Azure. 05:20.940 --> 05:23.160 The build the runtime stack is dotnet. 05:23.190 --> 05:24.510 Of course the version. 05:24.540 --> 05:25.800 Version nine. 05:26.040 --> 05:29.280 Obviously if you're in the future and it's dot net ten, great. 05:29.280 --> 05:31.080 Whatever it is, that's fine. 05:31.110 --> 05:36.360 Then we select how we want our GitHub action workflow to authenticate to Azure. 05:36.390 --> 05:42.390 If you choose user assigned identity, the identity selected will be federated with GitHub as an authorized 05:42.390 --> 05:45.090 client and given write permissions to the app. 05:45.090 --> 05:46.890 So that's the one that we'll use. 05:46.890 --> 05:50.700 And then the Azure subscription for the identity. 05:51.330 --> 05:54.090 We will select create New. 05:54.120 --> 06:02.130 And effectively Azure is going to create an identity specifically for authenticating our workflow to 06:02.160 --> 06:02.520 Azure. 06:02.550 --> 06:04.800 So we can leave that as create new. 06:04.830 --> 06:10.380 If I look in this list I've got various identities being created for different projects on here that 06:10.380 --> 06:15.840 gets created automatically for us as long as we leave that selected to create new. 06:15.840 --> 06:19.770 And this is going to create a workflow configuration file for us. 06:19.770 --> 06:21.780 So if I click on preview file. 06:21.810 --> 06:25.290 Then this is what it's going to create in our GitHub. 06:25.290 --> 06:26.520 Now notice the path. 06:26.520 --> 06:30.150 It's going to be in a path called GitHub workflows. 06:30.150 --> 06:33.090 Main underscore restore course dot YAML. 06:33.120 --> 06:36.240 And inside here is the workflow itself. 06:36.780 --> 06:38.250 What this will do. 06:38.820 --> 06:43.830 It's got a name build and deploy etc. but on push to the main branch. 06:43.830 --> 06:49.110 And this workflow dispatch means that we can also run this workflow manually on demand. 06:49.140 --> 06:53.310 It's got a job inside here and it runs on windows latest. 06:53.340 --> 06:58.590 GitHub is going to start a virtual server to run our workflows. 06:59.400 --> 07:02.880 So it uses a windows server effectively in the background. 07:03.390 --> 07:05.550 And then it goes through a number of steps. 07:05.550 --> 07:07.080 It first of all checks out our code. 07:07.080 --> 07:12.030 It sets up dotnet core with the correct version. 07:12.030 --> 07:14.580 It then runs a build of our application. 07:14.580 --> 07:20.400 It then publishes our application or runs the publish command, just as we did manually when we did 07:20.400 --> 07:23.970 this ourselves and outputs it to a directory called My App. 07:24.300 --> 07:28.330 And then it uploads artifacts and then we deploy it to Azure. 07:28.360 --> 07:36.730 And what this does is it uses secrets from GitHub that this is going to supply to GitHub directly. 07:36.730 --> 07:39.070 We don't need to configure GitHub with anything. 07:39.100 --> 07:46.510 Azure is going to take care of this for us with the identification the user identity is creating over 07:46.510 --> 07:47.230 here. 07:47.410 --> 07:51.700 And then it's going to deploy it to our app so we can close this. 07:51.700 --> 07:54.640 This is just a preview of the file that it is going to create. 07:54.640 --> 07:55.660 So I'll click close. 07:55.660 --> 08:00.280 And then all we need to do then is just save. 08:00.280 --> 08:04.750 And this is going to deploy something to GitHub. 08:04.750 --> 08:06.370 So I'll click save. 08:06.370 --> 08:08.620 And this will set up the deployment. 08:08.620 --> 08:09.700 And great. 08:09.730 --> 08:11.740 Now that's successfully set up. 08:11.740 --> 08:19.930 If we go back to GitHub and let's just go back to our code and then go to actions, what we find is 08:19.930 --> 08:22.300 that we've got a workflow running. 08:22.330 --> 08:24.100 Now this may or may not work. 08:24.100 --> 08:25.930 Let's go and take a look inside here. 08:25.930 --> 08:29.400 We've got two steps in here the build step and the deploy step. 08:29.400 --> 08:37.950 If we go and take a look at the build step, then it's running actions, checkouts, etc. and this is 08:37.950 --> 08:39.270 going to take a moment or two. 08:39.300 --> 08:47.250 Now this is not going to deploy our changes because we didn't commit them to GitHub yet from our local 08:47.250 --> 08:48.180 machine. 08:48.420 --> 08:56.280 So I'm just going to pause the video and see how this gets on and come back when something significant 08:56.280 --> 08:57.480 has happened. 08:57.510 --> 08:58.020 Okay. 08:58.050 --> 09:00.600 It certainly seems it got further than it did in testing. 09:00.600 --> 09:01.590 So that's a good start. 09:01.590 --> 09:05.850 And if I click on the deploy step then we'll go through the logs inside this one. 09:05.850 --> 09:09.120 Once again I just want to make sure this happens successfully. 09:09.120 --> 09:14.490 So I'll just keep an eye on these logs as well because this part is making me slightly nervous. 09:14.490 --> 09:18.360 And I'll come back once something significant has happened here. 09:18.390 --> 09:19.020 Okay. 09:19.020 --> 09:19.530 That's good. 09:19.530 --> 09:24.780 Whatever bug there was in place with the workflow previously, looks like it has been resolved now, 09:24.780 --> 09:32.000 and without making any changes to the workflow configuration file that Azure provided, the deployment 09:32.000 --> 09:37.160 did take place successfully, but it hasn't done anything to our application because nothing changed 09:37.160 --> 09:41.030 in our application for the commits that Azure was working with. 09:41.030 --> 09:49.010 Because Azure is working from our code, and if we take a look at our commits, then we've got a commit. 09:49.010 --> 09:51.470 But this one is committed by Azure. 09:51.560 --> 09:55.100 And if we take a look at this commit we've got our pre publish here. 09:55.100 --> 09:59.210 And if we take a look at this commit the changes inside here. 09:59.240 --> 10:00.980 The only change is the workflow. 10:00.980 --> 10:06.950 It doesn't include our code changes that we've made locally on our developer machine. 10:06.950 --> 10:08.510 So we've got a bit of work to do. 10:08.510 --> 10:14.390 And what I'd also like to happen is it also builds our react application at the same time, so that 10:14.390 --> 10:16.940 we don't have to do that step manually ourselves. 10:16.940 --> 10:21.170 Not that that's a big significant step, but it is very easy to forget. 10:21.410 --> 10:27.590 And if we have our workflow building our react application, it's just one more thing that we don't 10:27.590 --> 10:28.550 need to think about. 10:28.550 --> 10:34.790 And we're going to take a look at customizing this workflow and actually deploying our updated code 10:34.790 --> 10:35.870 in the next lesson.