-An important practice to get all of this to work is - -2
-continuous integration, which means integrating and - -3
-testing every few hours, or a - -4
-day at most, because we don't want problems to pile up and - -5
-to be discovered too late when there are too many of them - -6
-to fix. So what goes on here is a cycle. And the - -7
-cycle starts with the developer's programming, as soon as the developers are - -8
-done modifying the code and they have a stable version they will - -9
-run the local tests. If the local tests fail, the developers will - -10
-go back to programming to fix their code and possibly add - -11
-new code as needed, and this cycle, mini cycle will continue - -12
-until all the local tests pass. At that point the developers - -13
-can integrate their code with the code of other developers. And they - -14
-can run test for the integrated system, and when they run - -15
-this test again there are two possibilities. The test might fail, and - -16
-if the test fails you broke it, and therefore you'll have - -17
-to fix it. So developers will have to go back and modify - -18
-the system and again going through the cycle of running the local - -19
-tests, integrating, and running the systems - -20
-tests. Conversely, if all the systems - -21
-tests pass, then at that point the code is good to go - -22
-and it is integrated into the system. And it will be the problem - -23
-of some other developers if something breaks because at the time you - -24
-integrated your code, the code was compiling, running and passing the tests - -25
-successfully. So again, if we do this every few hours or every - -26
-day, we can find problems very early, and we can avoid the situations - -27
-in which we have many different changes coming from - -28
-many different developers in a integration nightmare as a result. -- cgit 1.4.1