1 00:00:01,700 --> 00:00:06,740 This later, we're going to take a look on how you can use much request and branches in order to improve 2 00:00:06,740 --> 00:00:10,440 your overall kit workflow when using catalepsy. 3 00:00:12,790 --> 00:00:17,320 Working with the branches is a good way of avoiding a master branch that cannot be deployed. 4 00:00:17,860 --> 00:00:23,890 And we have seen previously that whenever a developer goes into a monster branch and makes a change, 5 00:00:24,560 --> 00:00:30,930 a simple example was removing an import that the entire muther branch is no longer deployable. 6 00:00:31,570 --> 00:00:35,890 And this is, of course, very unfortunate and it really can affect the entire work. 7 00:00:36,670 --> 00:00:43,720 So the idea of working with branches is that each developer or each new feature can be deployed to a 8 00:00:43,720 --> 00:00:52,330 specific branch, can be tested, and when it's ready for March, it can be merged into master back 9 00:00:52,480 --> 00:00:54,970 and it can then be deployed on production. 10 00:00:55,660 --> 00:01:03,910 And using this workflow really makes it much easier and guarantees that the master branch is always 11 00:01:03,910 --> 00:01:08,040 deployable and this is actually part of continuous deployment. 12 00:01:08,410 --> 00:01:11,860 You want to be able all the time to deploy your software. 13 00:01:11,860 --> 00:01:18,100 And if the master branch isn't working because somebody has made a small mistake and everything stops 14 00:01:18,100 --> 00:01:24,790 working, then this is not really going into the direction of continuous deployment and continuous delivery. 15 00:01:26,290 --> 00:01:31,390 Now, there are different strategies, also known as branching models for dealing with the situation. 16 00:01:31,840 --> 00:01:36,540 Gitlow is one example of them, but I will not go into details. 17 00:01:36,550 --> 00:01:43,360 It's totally up to you how you want to do it and which workflow better suits your own organization. 18 00:01:43,780 --> 00:01:48,190 But I would generally advise against only using the master for this. 19 00:01:48,890 --> 00:01:50,890 Of course, you can make it much simpler. 20 00:01:50,890 --> 00:01:55,630 Not every feature, not every bug needs to go to a specific branch. 21 00:01:56,860 --> 00:01:57,880 It can be fairly easy. 22 00:01:57,880 --> 00:02:02,270 Separate your workflows in a develop and in a master branch. 23 00:02:02,310 --> 00:02:07,720 In develop is like the developing workflow you can break to develop and you can later fix it. 24 00:02:07,720 --> 00:02:13,090 That would not be a problem and only when you're ready to make a release, you can merge all your changes 25 00:02:13,090 --> 00:02:14,730 from the developer branched master. 26 00:02:15,160 --> 00:02:18,160 But this is a bit a different workflow from what I wanted to show you. 27 00:02:18,400 --> 00:02:25,600 I just wanted to show you a workflow where you can do as much request branches and sort of on each feature 28 00:02:25,600 --> 00:02:26,950 goes into a branch. 29 00:02:31,690 --> 00:02:37,450 Before we can use branches, there are a couple of things that we need to fix about our pipeline now 30 00:02:37,450 --> 00:02:43,540 by default, what will happen is that if we create a new branch and push it, this pipeline will be 31 00:02:43,540 --> 00:02:45,880 executed for that specific branch as well. 32 00:02:46,510 --> 00:02:51,880 Now, generally, they are a couple of steps where it makes sense to execute a pipeline. 33 00:02:52,090 --> 00:02:55,330 So, for example, we want to build an artifact. 34 00:02:55,330 --> 00:03:00,040 We still want to build an artifact, and we still want to test if that artifact works. 35 00:03:00,040 --> 00:03:04,780 And we still want to locally start the website to see if the website works. 36 00:03:05,560 --> 00:03:13,300 But we definitely do not want to deploy to staging or to production from our branch or to run production 37 00:03:13,300 --> 00:03:14,300 tests or something like that. 38 00:03:14,680 --> 00:03:19,420 So this area here is definitely something that we do not want to do inside a branch. 39 00:03:20,220 --> 00:03:22,390 And luckily, we can configure that. 40 00:03:22,390 --> 00:03:26,980 We can specify that these three jobs will only be executed on M.. 41 00:03:27,130 --> 00:03:28,270 And this is quite easy. 42 00:03:28,470 --> 00:03:29,170 I'll show you. 43 00:03:30,690 --> 00:03:35,730 So by using only, we can set this policy to follow a specific rule. 44 00:03:37,320 --> 00:03:39,090 So we're going to say only master. 45 00:03:43,450 --> 00:03:46,480 And this will make this job only execute on Mr.. 46 00:03:49,980 --> 00:03:52,350 The thing we're going to do for deployed to production. 47 00:04:02,420 --> 00:04:03,710 And for the production tests. 48 00:04:10,540 --> 00:04:15,370 So let's now committee's changes, and after that, we're going to create the branch. 49 00:04:20,300 --> 00:04:24,340 I am going back to get Lamp and I want to create a new branch. 50 00:04:24,750 --> 00:04:29,870 Of course you can do it anywhere you want, but it will be much easier to demonstrate it from here. 51 00:04:30,270 --> 00:04:32,370 I'll go to repository branches. 52 00:04:36,000 --> 00:04:37,470 They're going to select new branch. 53 00:04:40,820 --> 00:04:46,340 Let's say that we want to add a different title to our website and name it feature. 54 00:04:48,360 --> 00:04:49,050 Your title. 55 00:04:52,210 --> 00:04:54,340 And I'm going to create this branch for Mostro. 56 00:05:00,520 --> 00:05:04,270 As soon as I've created this brunch, the pipeline will start. 57 00:05:08,180 --> 00:05:13,730 And you will see that the pipeline itself is much shorter, so we don't only build a website and then 58 00:05:13,730 --> 00:05:20,690 go to testing and if everything looks good, then we can say we are ready to march this branch back 59 00:05:20,750 --> 00:05:21,590 into the master.