1
00:00:02,560 --> 00:00:10,960
By now, you're probably wondering what exactly is S.I CD or continuous integration, continuous delivery,

2
00:00:10,960 --> 00:00:16,160
continuous deployment so many times and I ironically, does it affect us?

3
00:00:16,180 --> 00:00:18,420
Why should we care about us or what?

4
00:00:18,430 --> 00:00:21,260
What are these only buzzwords or what do they mean?

5
00:00:21,610 --> 00:00:25,390
So let's first start with continuous integration and understand what continuous integration is.

6
00:00:26,470 --> 00:00:29,950
And actually the continuous integration is simply a practice.

7
00:00:30,400 --> 00:00:36,170
And when you are using continuous integration, you're integrating your code with other developers.

8
00:00:36,490 --> 00:00:39,760
Now, usually you're not the only one working on a project.

9
00:00:40,480 --> 00:00:47,950
And by using continuous integration, what it means is that every time you make a change to the code,

10
00:00:48,250 --> 00:00:52,060
that code is being integrated with the work that I just did.

11
00:00:52,840 --> 00:00:58,420
And usually the way of integrating this is to see if the build is still running.

12
00:00:58,460 --> 00:01:02,800
So, for example, you have a compile task or you're somehow building the project.

13
00:01:02,800 --> 00:01:08,890
And if that task doesn't work anymore, then it means that the last one, probably the last one who

14
00:01:08,890 --> 00:01:13,130
has made a change to the project did something that made the project not work anymore.

15
00:01:13,810 --> 00:01:16,060
So this is one step of continuous integration.

16
00:01:16,420 --> 00:01:21,650
The other step would be, of course, to see if everything still works, if you test it.

17
00:01:22,420 --> 00:01:25,030
So let's say the project is still building properly.

18
00:01:25,030 --> 00:01:25,870
There are no errors.

19
00:01:26,680 --> 00:01:33,040
But if you're working on a website or any product, if the core functionality of that product isn't

20
00:01:33,040 --> 00:01:39,070
working anymore, we usually check such things in an automatic way by writing tests.

21
00:01:39,070 --> 00:01:41,490
And there are different levels of tests that we can write.

22
00:01:41,920 --> 00:01:44,040
But this is generally continuous integration.

23
00:01:44,050 --> 00:01:48,640
We try to integrate the work that we do all the time continuously.

24
00:01:48,640 --> 00:01:55,600
So there's no we integrate our work once a week and after one week nothing works anymore.

25
00:01:56,080 --> 00:02:02,830
We constantly integrate every change that you do to a repository, or if the project is spent over multiple

26
00:02:02,830 --> 00:02:10,389
repositories, every work, every change that is done there is integrated with the work of other developers,

27
00:02:10,389 --> 00:02:16,480
other people working on the same project as early as possible so that we can get continuous feedback

28
00:02:16,480 --> 00:02:18,740
and to know what you have changed.

29
00:02:18,750 --> 00:02:22,720
The project has is actually incompatible with what have changed.

30
00:02:23,150 --> 00:02:27,010
So let's try to find a way and fix the project so that it works for everybody.

31
00:02:28,500 --> 00:02:35,700
Continuous delivery is after continuous integration, and usually you cannot do continuous delivery

32
00:02:35,700 --> 00:02:37,770
without doing continuous integration first.

33
00:02:38,200 --> 00:02:45,540
And the idea between continuous delivery is that in the previous step you have created a package or

34
00:02:45,540 --> 00:02:53,550
something that you can deliver to production and you're automatically installing this package on a staging

35
00:02:53,550 --> 00:02:58,470
system, on a pre production or testing, or there are different names for it.

36
00:02:58,470 --> 00:03:07,020
But on a system that doesn't go live, doesn't affect real customers or whoever is using this software

37
00:03:07,020 --> 00:03:07,440
product.

38
00:03:08,160 --> 00:03:14,760
So the idea between continuous delivery is to build packages all the time and to install them in an

39
00:03:14,760 --> 00:03:19,560
environment and only by using manual intervention.

40
00:03:19,920 --> 00:03:25,530
You can decide if a specific package, if a specific change said should go life.

41
00:03:25,980 --> 00:03:31,800
And usually you'll have this review system where somebody looks, oh, these are the changes that will

42
00:03:31,800 --> 00:03:32,370
go live.

43
00:03:33,600 --> 00:03:36,840
Is it OK from a business standpoint and so on and so forth.

44
00:03:37,260 --> 00:03:40,920
And then we'll say, OK, this is this looks good.

45
00:03:41,250 --> 00:03:43,650
I'm going to decide that this can go life.

46
00:03:43,950 --> 00:03:46,830
So it's only automatically installed in one system.

47
00:03:47,250 --> 00:03:53,210
And after a manual check, it can be installed on a production system as well.

48
00:03:53,910 --> 00:04:01,440
Now, continuous deployment in this case goes even further and you can more or less say that every change

49
00:04:01,440 --> 00:04:08,850
to the project goes to the continuous integration stage, usually goes to a preproduction stage where

50
00:04:08,850 --> 00:04:09,990
you check again.

51
00:04:10,590 --> 00:04:17,370
And if there all the tests are good, then it means that this package that you now have can go to production

52
00:04:17,370 --> 00:04:17,790
as well.

53
00:04:18,459 --> 00:04:24,900
And if all the previous stages are successful with continuous deployment, will actually push those

54
00:04:24,900 --> 00:04:26,650
changes to production automatically.

55
00:04:27,000 --> 00:04:32,970
So this review step, this manual intervention that somebody looks again at a system and says, oh,

56
00:04:32,970 --> 00:04:36,060
this is good, can go to production, totally disappears.

57
00:04:36,250 --> 00:04:41,970
And more or less every change that is made in the repository will go to production automatically.

58
00:04:42,660 --> 00:04:47,060
And in this case, you will have multiple deployments per day.

59
00:04:48,240 --> 00:04:55,740
So the advantages of continuous integrations are generally related to detecting errors and fixing problems

60
00:04:55,740 --> 00:04:57,720
or bugs as soon as possible.

61
00:04:57,720 --> 00:05:03,630
And when you're integrating multiple times a Gayton with which every change that you made to a repository

62
00:05:03,630 --> 00:05:07,260
is being integrated, it really reduces integration problems.

63
00:05:07,260 --> 00:05:12,900
Or if there are any integration problems, they are generally pretty small and can be easier to be dealt

64
00:05:12,900 --> 00:05:19,530
with than to avoid doing integration for a large period of time and then to do it much later.

65
00:05:20,970 --> 00:05:29,130
This also allows developers to work much faster to create smaller changes to the code base and to have

66
00:05:29,130 --> 00:05:35,150
more confidence that whatever they do, it will be easily detected by the continuous integration server

67
00:05:35,160 --> 00:05:41,370
in this case, Getler, because every time you commit to change, that change will be integrated with

68
00:05:41,370 --> 00:05:42,210
all other changes.

69
00:05:42,510 --> 00:05:48,360
There will be tests that will be executed and hopefully any major bugs will be detected right there.

70
00:05:49,950 --> 00:05:56,280
Addition, when doing continuous delivery and continuous deployment, it's more or less you make sure

71
00:05:56,280 --> 00:06:02,250
that everything you do is actually releasable so you don't make any changes that are not designed to

72
00:06:02,250 --> 00:06:02,760
go life.

73
00:06:02,760 --> 00:06:08,460
Or if you make any changes, you sort of will make sure that those changes are not accessible.

74
00:06:09,360 --> 00:06:15,240
Additionally, if you're doing smaller changes and they go to production quite often, is that it lowers

75
00:06:15,240 --> 00:06:15,640
the risk.

76
00:06:15,990 --> 00:06:21,330
Now, it doesn't mean that there's absolutely no risk and this generally means that.

77
00:06:22,480 --> 00:06:30,190
Changes that introduce problems are easier to detect and are much easier to fix, and this is totally

78
00:06:30,190 --> 00:06:37,120
different from doing like very big releases where you're only deploying once a month or something like

79
00:06:37,120 --> 00:06:42,430
that, where you have a lot of changes and and is more or less well, hopefully everything works because

80
00:06:42,430 --> 00:06:44,190
if it doesn't work, then we have a problem.

81
00:06:45,480 --> 00:06:48,970
And actually, by deploying so frequently, you deliver more value.

82
00:06:48,990 --> 00:06:55,450
So you're building a product because you are building some features that somebody needs.

83
00:06:56,310 --> 00:07:03,770
And if you're delivering that features faster to the market, you have on one side a competitive advantage.

84
00:07:04,140 --> 00:07:08,380
But on the other side, you also get more feedback from your customers.

85
00:07:08,460 --> 00:07:14,310
So so why make the customers wait for one month, give you feedback when they can give you feedback

86
00:07:14,310 --> 00:07:19,860
in a couple of days and then work on that feedback or based on the box or problems they detected, you

87
00:07:19,860 --> 00:07:22,830
can make another iteration and make everything much faster.

88
00:07:25,250 --> 00:07:30,080
Now, in this lecture, I've tried to give you an overview of what continuous integration, continuous

89
00:07:30,080 --> 00:07:35,540
delivery and continuous deployment really mean, but you will see in the next lectures and in this entire

90
00:07:35,540 --> 00:07:43,100
course will be going and demonstrating exactly how this concepts, how this practice of integrating

91
00:07:43,100 --> 00:07:47,890
code and practice of continuously delivering code can be implemented with catalepsy.

92
00:07:48,140 --> 00:07:49,880
And this is the most interesting part.

93
00:07:50,150 --> 00:07:55,550
And I'm sure that when you will be doing it on your own, it will have a much better understanding than

94
00:07:55,760 --> 00:08:01,910
watching the slides and saying, oh, lab OCI is when you're doing this and this and CCDs when you're

95
00:08:01,910 --> 00:08:06,440
doing this, you will have the chance of actually practicing this on your own.

