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