1 00:00:00,940 --> 00:00:02,410 Our project is now looking pretty good. 2 00:00:02,470 --> 00:00:04,780 And now it's time for us to actually deploy it. 3 00:00:05,260 --> 00:00:06,430 This is going to be a lot of fun. 4 00:00:06,460 --> 00:00:10,450 We're going to walk through the process of creating a production style deployment pipeline. 5 00:00:11,130 --> 00:00:14,920 And when we talk about deployment, it's not really just about making sure that our code is live somewhere. 6 00:00:15,250 --> 00:00:20,200 Instead, it's about the entire workflow and how we make sure that we can make changes, somehow save 7 00:00:20,200 --> 00:00:23,740 those changes and make sure those changes get deployed somewhere automatically. 8 00:00:24,580 --> 00:00:27,280 They're going to build out an entire workflow process here. 9 00:00:27,370 --> 00:00:29,890 We're not just going to look alone at doing the deployment stuff. 10 00:00:30,850 --> 00:00:31,060 All right. 11 00:00:31,100 --> 00:00:32,740 So, of course, a couple of quick diagrams. 12 00:00:33,670 --> 00:00:36,310 So here's the entire idea at some point time. 13 00:00:36,700 --> 00:00:40,090 You might have multiple different teams working on a single product. 14 00:00:40,690 --> 00:00:43,240 These two teams might be working on very different services. 15 00:00:43,450 --> 00:00:48,340 And after they make some changes to the services, we should expect that those changes will be eventually 16 00:00:48,340 --> 00:00:50,800 deployed into some production communities cluster. 17 00:00:51,670 --> 00:00:56,440 So we need a workflow to make sure that multiple teams can be working on the same project at the same 18 00:00:56,440 --> 00:01:01,990 time and eventually merge all these changes together and deploy them in some meaningful fashion without 19 00:01:01,990 --> 00:01:04,480 having some nasty conflicts or errors along the way. 20 00:01:05,940 --> 00:01:11,040 So I'm going to show you a little diagram or a workflow that I've personally used in many projects and 21 00:01:11,040 --> 00:01:13,920 I know many, many other engineers use in projects as well. 22 00:01:14,220 --> 00:01:16,890 It's a pretty foolproof diagram or really workflow. 23 00:01:17,160 --> 00:01:19,130 The first time you learn it, it's a little bit confusing. 24 00:01:19,170 --> 00:01:22,530 But once you understand the idea behind it, the workflow is pretty bullet proof. 25 00:01:22,590 --> 00:01:25,290 And it's going to work in the vast, vast majority of scenarios. 26 00:01:25,860 --> 00:01:26,730 OK, so here it is. 27 00:01:27,910 --> 00:01:29,170 So this is the overall diagram. 28 00:01:29,500 --> 00:01:31,700 I'm going to zoom in and we're going to walk through it step by step. 29 00:01:34,120 --> 00:01:39,150 So we're starting off on your local machine where you are going to be working on some changes to some 30 00:01:39,150 --> 00:01:40,140 particular service. 31 00:01:40,770 --> 00:01:45,330 So we're going to imagine that you are making that change to, say, the ticket service after you have 32 00:01:45,330 --> 00:01:46,230 made your changes. 33 00:01:46,500 --> 00:01:51,000 You are then going to commit that code or those changes to a get branch. 34 00:01:51,540 --> 00:01:53,130 So we're going to created branch whip gets. 35 00:01:53,550 --> 00:01:55,590 We're going to commit all of our changes to that branch. 36 00:01:56,160 --> 00:02:01,380 The only requirement here is that we make changes and we commit them to any branch besides the master 37 00:02:01,380 --> 00:02:01,860 branch. 38 00:02:02,130 --> 00:02:05,920 We're going to treat the master branch as a very special branch in this workflow. 39 00:02:07,110 --> 00:02:10,590 After we have committed those changes will then push that branch up to get up. 40 00:02:11,740 --> 00:02:13,470 Then our workload jumps over to get up. 41 00:02:15,370 --> 00:02:17,330 Get Up is going to receive that update branch. 42 00:02:18,180 --> 00:02:20,700 You are then going to mainly create a pull request. 43 00:02:20,730 --> 00:02:22,110 Do you get Huub UI? 44 00:02:22,500 --> 00:02:27,510 A pull request is a request to essentially merge some changes from one branch into a another branch. 45 00:02:28,080 --> 00:02:31,800 In this case, we're going to make a pull request to merge changes from the branch you just created 46 00:02:31,830 --> 00:02:33,570 into the master branch. 47 00:02:34,690 --> 00:02:39,730 The instant that we create that play request, we are going to configure GitHub to automatically run 48 00:02:39,760 --> 00:02:44,500 all the tests inside of our project by just creating this pull request. 49 00:02:44,830 --> 00:02:48,610 We're going to make sure that GitHub runs all those different tests we have created over time. 50 00:02:50,670 --> 00:02:56,010 After all those tests pass, we are then going to merge our pull request into the master branch. 51 00:02:56,550 --> 00:02:59,940 Like I said, the Master Branch is going to be a very special branch inside of rap. 52 00:03:00,450 --> 00:03:04,800 Whenever we make a change to the master branch, we're going to configure GitHub so that it automatically 53 00:03:04,800 --> 00:03:08,280 deploys all of our changes to our live Cuban natives cluster. 54 00:03:09,120 --> 00:03:12,870 You'll notice that in this entire workflow, we haven't really said that much about deployment or where 55 00:03:12,870 --> 00:03:14,250 we are deploying are up to. 56 00:03:14,630 --> 00:03:20,160 But this is really a very generic general workflow that you can use to deploy code to any kind of target 57 00:03:20,160 --> 00:03:22,830 to be at Google Cloud eight of us or anything else. 58 00:03:24,310 --> 00:03:26,740 All right, now, you've seen a very rough outline here. 59 00:03:26,950 --> 00:03:28,270 We're going to take a quick pause. 60 00:03:28,300 --> 00:03:32,380 When we come back, the next video, we're going to create a get repository on our local machine. 61 00:03:32,830 --> 00:03:35,080 We're also going to create a get repository on GitHub. 62 00:03:35,320 --> 00:03:37,810 We're going to tie the two together and just do a little bit of setup.