1
00:00:01,200 --> 00:00:06,540
In this lecture, we are going to take a look at how you can configure specific jobs to be triggered

2
00:00:06,630 --> 00:00:07,710
manually only.

3
00:00:11,330 --> 00:00:17,390
So let's take a moment to revisit our continuous deployment pipeline, and as you remember, we said

4
00:00:17,390 --> 00:00:22,640
that until the changing environment, we can do everything automatically.

5
00:00:22,640 --> 00:00:27,320
So we deploy on other environments and we have that already.

6
00:00:27,330 --> 00:00:32,600
We have only the staging environment, but everything is going automatic is said.

7
00:00:32,750 --> 00:00:35,750
We want to have like a manual review process.

8
00:00:35,760 --> 00:00:39,470
We don't want to go to production automatically as we do right now.

9
00:00:39,920 --> 00:00:46,370
We want to have somebody manually triggering a deployment, eventually looking what's on staging.

10
00:00:46,730 --> 00:00:49,130
Is this something that don't want to have on production as well?

11
00:00:49,940 --> 00:00:54,110
And as you have seen so far, this goes automatically in Gottleib.

12
00:00:54,590 --> 00:00:58,210
You'll nobody ask you if you want to deploy to production, it just deploys.

13
00:00:58,210 --> 00:01:04,590
So as long as that staging environment works and any other stages before, it just goes to production.

14
00:01:05,390 --> 00:01:10,820
So what we will do in this lecture, we are going to get this manual intervention step so that we deploy

15
00:01:10,820 --> 00:01:15,590
to production only when we mentally decide that this is what we want.

16
00:01:16,680 --> 00:01:22,740
So for that, we're going to edit our pipeline and the job that we want to change is actually deployed

17
00:01:22,740 --> 00:01:23,400
to production.

18
00:01:24,960 --> 00:01:30,000
So the additional configuration that we can edit here is to add a when.

19
00:01:32,410 --> 00:01:33,430
And to say, Manuel.

20
00:01:36,280 --> 00:01:44,080
So this specific job will only be triggered when we manually click into the interface and I'll be able

21
00:01:44,080 --> 00:01:48,220
to show you how exactly this works after I commit and let the pipeline run.

22
00:01:53,210 --> 00:01:58,580
So if you now take a look at our pipeline, you will see that deploy production looks a bit different

23
00:01:58,940 --> 00:02:00,560
and it hasn't been executed.

24
00:02:01,340 --> 00:02:07,010
But what's surprising a bit is that next, the stage production test has been executed.

25
00:02:07,010 --> 00:02:13,960
And, of course, because the wrong version is still available online, the test in this case failed.

26
00:02:14,900 --> 00:02:16,310
But we'll fix that a bit later.

27
00:02:17,240 --> 00:02:24,410
So what we wanted to achieve is actually to not allow a deployment on production without first checking

28
00:02:24,410 --> 00:02:26,350
to see what's going on.

29
00:02:27,800 --> 00:02:29,840
We can even go again back to environments.

30
00:02:32,050 --> 00:02:38,110
And you will be able to see that staging and production have different versions, so you will see a

31
00:02:38,110 --> 00:02:42,820
different committee hashes, which is consistent with what we see in our pipeline.

32
00:02:42,850 --> 00:02:47,080
So this all indicates that we haven't done a production deployment yet.

33
00:02:47,410 --> 00:02:49,180
So let's go ahead and do it.

34
00:02:50,060 --> 00:02:51,520
I'm going to open the pipeline again.

35
00:02:53,620 --> 00:02:56,230
And all I need to do is simply click on this job.

36
00:02:59,970 --> 00:03:01,700
And now it will start the deployment.

37
00:03:06,370 --> 00:03:13,030
And a few moments later, deploy to a production has been successful as well, but we still see that

38
00:03:13,030 --> 00:03:16,060
the production tests are failing now.

39
00:03:16,060 --> 00:03:22,150
They haven't been started again, and we can manually fix them by clicking the retry button and see

40
00:03:22,150 --> 00:03:23,980
if the deployment now is successful.

41
00:03:29,180 --> 00:03:32,010
Now, the production tests have passed as well.

42
00:03:32,030 --> 00:03:34,850
And now the entire pipeline is successful.

43
00:03:37,780 --> 00:03:43,570
Now, of course, the way it is right now isn't really the way we would like to have, because the normal

44
00:03:43,570 --> 00:03:50,590
expectation would be if you introduce here a manual step, that the rest of the stages won't be executed.

45
00:03:50,920 --> 00:03:56,620
And unfortunately, this is not the default behavior in Getler, but we still have the possibility of

46
00:03:56,620 --> 00:03:57,220
changing that.

47
00:03:57,430 --> 00:04:00,370
So let's go back to our code editor and make a small change.

48
00:04:01,870 --> 00:04:07,630
Now, what is actually missing in order to get the behavior that you want so that we can wait after

49
00:04:07,630 --> 00:04:12,480
this manual stage and not execute a production test is to add the following line.

50
00:04:13,150 --> 00:04:16,390
And this is a low on this car failure, false.

51
00:04:17,329 --> 00:04:19,660
And all this is not very intuitive.

52
00:04:19,660 --> 00:04:22,750
And I will include the official documentation on this one.

53
00:04:23,170 --> 00:04:25,560
But this should fix our problem.

54
00:04:26,140 --> 00:04:28,180
So let's see if it works as we expect.

55
00:04:33,770 --> 00:04:39,500
Now, if we look again at our pipeline, you will see that the status is blocked, so let's go ahead

56
00:04:39,500 --> 00:04:40,760
and see how it looks now.

57
00:04:45,800 --> 00:04:51,980
So it seems that the change that we have done works properly, because you can see deployed production

58
00:04:52,130 --> 00:04:57,500
hasn't been executed yet and waits for the manual action and the production tests are waiting for the

59
00:04:57,500 --> 00:04:58,160
previous stage.

60
00:04:58,550 --> 00:04:59,780
So it looks all good.

61
00:04:59,780 --> 00:05:01,880
I'm going to deploy now.

62
00:05:04,950 --> 00:05:07,950
And the production test will be started right after this.

63
00:05:08,880 --> 00:05:16,250
So this is how you can implement a continuous delivery pipeline with manual actions or any other manual

64
00:05:16,260 --> 00:05:18,170
actions that you need inside your pipeline.

65
00:05:22,270 --> 00:05:28,090
So just a short recap, what we have done is to add this additional condition for the Duplo production

66
00:05:28,090 --> 00:05:36,460
job when Manuell and because we had additional stages after this stage that we wanted to block, we

67
00:05:36,460 --> 00:05:42,220
added this additional condition, allow failure, which makes which blocks basically the entire pipeline

68
00:05:42,220 --> 00:05:46,980
waits for our manual action and only then executes the rest of the stages.

69
00:05:49,920 --> 00:05:55,590
Now, we won't need this anymore, so for that reason, I will remove it from the pipeline and we'll

70
00:05:55,590 --> 00:05:58,620
continue doing continuous deployments to production.

