From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001
From: Nguyễn Gia Phong <mcsinyx@disroot.org>
Date: Sun, 24 May 2020 16:34:31 +0700
Subject: [usth/ICT2.7] Engineer software

---
 .../12 - Continuous Integration - lang_en_vs4.srt  | 111 +++++++++++++++++++++
 1 file changed, 111 insertions(+)
 create 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
new file mode 100644
index 0000000..d40bda6
--- /dev/null
+++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt	
@@ -0,0 +1,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.
-- 
cgit 1.4.1