about summary refs log tree commit diff
path: root/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt
blob: d40bda6903c66b7811585cf7707b00a932bb6e68 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
1
00:00:00,280 --> 00:00:02,980
An important practice to get all of this to work is

2
00:00:02,980 --> 00:00:05,230
continuous integration, which means integrating and

3
00:00:05,230 --> 00:00:06,770
testing every few hours, or a

4
00:00:06,770 --> 00:00:10,390
day at most, because we don't want problems to pile up and

5
00:00:10,390 --> 00:00:13,060
to be discovered too late when there are too many of them

6
00:00:13,060 --> 00:00:16,020
to fix. So what goes on here is a cycle. And the

7
00:00:16,020 --> 00:00:19,380
cycle starts with the developer's programming, as soon as the developers are

8
00:00:19,380 --> 00:00:22,050
done modifying the code and they have a stable version they will

9
00:00:22,050 --> 00:00:25,380
run the local tests. If the local tests fail, the developers will

10
00:00:25,380 --> 00:00:28,350
go back to programming to fix their code and possibly add

11
00:00:28,350 --> 00:00:31,990
new code as needed, and this cycle, mini cycle will continue

12
00:00:31,990 --> 00:00:35,000
until all the local tests pass. At that point the developers

13
00:00:35,000 --> 00:00:37,960
can integrate their code with the code of other developers. And they

14
00:00:37,960 --> 00:00:41,220
can run test for the integrated system, and when they run

15
00:00:41,220 --> 00:00:44,830
this test again there are two possibilities. The test might fail, and

16
00:00:44,830 --> 00:00:47,160
if the test fails you broke it, and therefore you'll have

17
00:00:47,160 --> 00:00:50,710
to fix it. So developers will have to go back and modify

18
00:00:50,710 --> 00:00:54,010
the system and again going through the cycle of running the local

19
00:00:54,010 --> 00:00:55,900
tests, integrating, and running the systems

20
00:00:55,900 --> 00:00:57,890
tests. Conversely, if all the systems

21
00:00:57,890 --> 00:01:00,150
tests pass, then at that point the code is good to go

22
00:01:00,150 --> 00:01:02,500
and it is integrated into the system. And it will be the problem

23
00:01:02,500 --> 00:01:05,370
of some other developers if something breaks because at the time you

24
00:01:05,370 --> 00:01:09,530
integrated your code, the code was compiling, running and passing the tests

25
00:01:09,530 --> 00:01:12,495
successfully. So again, if we do this every few hours or every

26
00:01:12,495 --> 00:01:15,740
day, we can find problems very early, and we can avoid the situations

27
00:01:15,740 --> 00:01:18,105
in which we have many different changes coming from

28
00:01:18,105 --> 00:01:21,290
many different developers in a integration nightmare as a result.