1 files changed, 0 insertions, 111 deletions
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.