From 8a7dfa0972c83fd811a4296e7373574bea4a28d0 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 19 Jul 2020 20:34:40 +0700 Subject: [usth/ICT2.7] Remove Udacity transcribes --- .../12 - Continuous Integration - lang_en_vs4.srt | 111 --------------------- 1 file changed, 111 deletions(-) delete mode 100644 usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt (limited to 'usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt') diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt deleted file mode 100644 index d40bda6..0000000 --- a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt +++ /dev/null @@ -1,111 +0,0 @@ -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. -- cgit 1.4.1