1
00:00:04,100 --> 00:00:10,070
As part of the deployment process, we want to make sure that the version that we have built and deployed

2
00:00:10,340 --> 00:00:15,590
is actually available in production, and because we want to automate things, we don't want to go to

3
00:00:15,590 --> 00:00:19,070
the console to see old version seven is running.

4
00:00:19,370 --> 00:00:21,830
We want to find a different way on how to do that.

5
00:00:23,190 --> 00:00:28,350
If you open Posman again and select the production environment, you'll be able to manually test the

6
00:00:28,350 --> 00:00:28,950
application.

7
00:00:29,460 --> 00:00:34,620
The first thing that we're interested in is to check if the health status is up.

8
00:00:34,630 --> 00:00:38,040
So if the application itself reports that everything is OK.

9
00:00:38,610 --> 00:00:43,350
Additionally, there's an informal point that can give us additional information.

10
00:00:43,530 --> 00:00:49,500
Now currently is not populated with any data, but whether we can do is to replace this information

11
00:00:49,500 --> 00:00:55,980
here with actual data during the process and then when the application is deployed, will be able to

12
00:00:55,980 --> 00:00:59,430
ask the application, hey, tell me, which version are you currently in?

13
00:00:59,640 --> 00:01:05,069
And if the application reports, hey, now I'm version seven and we will know that application that

14
00:01:05,069 --> 00:01:07,140
we have built is now actually alive.

15
00:01:07,380 --> 00:01:12,750
So we will not have to only rely on a table worth reporting and saying, hey, I have the Buddhist,

16
00:01:12,750 --> 00:01:13,350
trust me.

17
00:01:13,440 --> 00:01:15,840
So we'll have an additional way on how to check this.

18
00:01:18,110 --> 00:01:25,550
Just in case you're wondering from where the variables are coming from, you can go to source main resources

19
00:01:25,820 --> 00:01:27,040
and application Yamal.

20
00:01:27,440 --> 00:01:30,590
This is where the application starts some information.

21
00:01:30,830 --> 00:01:33,520
And one of those details is regarding the info.

22
00:01:33,680 --> 00:01:39,350
And these are just placeholders here and we're going to replace them in our little FCI pipeline.

23
00:01:41,850 --> 00:01:46,210
And we need to replace these variables before the actual build process has started.

24
00:01:46,230 --> 00:01:49,970
So we're actually modifying the application that before the built.

25
00:01:50,460 --> 00:01:53,160
So in order to achieve that, we're going to use said.

26
00:01:53,490 --> 00:01:57,530
And the syntax for said was said minus I.

27
00:01:57,810 --> 00:02:05,190
And then we'll specify what we want to search for in this case is the pipeline idea.

28
00:02:08,190 --> 00:02:14,490
And this will be a string and we're going to replace this with an environment variable S.I Pipeline

29
00:02:14,490 --> 00:02:17,570
Idy, and this will be the idea for the pipeline.

30
00:02:18,360 --> 00:02:24,600
You can see I have named the placeholder exactly as the predefined lecci variable, but you can use

31
00:02:24,600 --> 00:02:26,610
any name for the placeholder you like.

32
00:02:26,640 --> 00:02:29,550
I just wanted to make it consistent and easy to understand.

33
00:02:29,730 --> 00:02:34,240
And let's also add here slash at the end to make the syntax valid.

34
00:02:34,920 --> 00:02:39,060
After that, we're going to get to pass through the application, Yamal, because we need to reference

35
00:02:39,060 --> 00:02:40,290
which file this will be.

36
00:02:40,650 --> 00:02:42,930
For that, I'm going to go here, copy path.

37
00:02:43,200 --> 00:02:46,740
And the path that I'm interested in is from the repository route.

38
00:02:48,450 --> 00:02:54,150
Just going to make sure that I get the local reference here and this should be fine, and I'm going

39
00:02:54,150 --> 00:03:00,000
to duplicate this command for two other variables and I'm going to replace the variables there.

40
00:03:02,100 --> 00:03:03,720
So this will be the commit committed.

41
00:03:05,260 --> 00:03:09,160
Make sure to include a dollar sign and finally the branch.

42
00:03:14,070 --> 00:03:17,640
So I'm going to commit this little pipe and run and then take a look in Bowsman.

43
00:03:20,700 --> 00:03:25,680
And no enforcement after waiting for the deployment and keeping the production environment, and I'm

44
00:03:25,680 --> 00:03:31,410
going to call the important point again and you will be able to see inside and point.

45
00:03:31,440 --> 00:03:36,780
Now, the current version in my case, this is version nine is the committee that has generated this

46
00:03:36,780 --> 00:03:37,170
version.

47
00:03:37,170 --> 00:03:39,120
And now we are on the Masterbrand.

48
00:03:39,360 --> 00:03:41,100
This is just some generic information.

49
00:03:41,400 --> 00:03:46,380
Some of it will be relevant later, but it will help you identify which version is this?

50
00:03:46,380 --> 00:03:51,990
Which committee has generated this version based on this information, we can later automate the process

51
00:03:51,990 --> 00:03:53,870
and check this information.

52
00:03:53,880 --> 00:03:54,210
Right.

53
00:03:54,210 --> 00:03:55,230
And the deployment stage.