Comments by "" (@grokitall) on "What is Continuous Integration?" video.

  1. The reason it says do it more often is that a lot of the pain depends on the size of the change, and thus the difficulty in finding what to fix. By increasing the frequency you reduce the size of the change, and thus find the bit that caused the problem in a much smaller change. Doing version control more often reduces the size of the change, but having long lived feature branches causes merge hell. Integrating at least daily to mainline gets rid of merge hell, but amplifies the problem of lack of regression tests. Specifically that you tend to write hard to test code. Adding the regression tests with the new code, and having a ratchet on the code coverage so you cannot commit if it drops the percentage gradually fixes the regression test problem. This also gives you continuous integration if you run all the tests with every commit. However it increases your vulnerability to worthless and flaky tests and to the test suite being slow. By writing the tests first, you prove that they fail, and then when you add the new code, you prove that they pass, getting rid of worthless tests. Because this speeds up your progress, you have a bigger problem with technical debt. By adding regression testing to the cycle, you deal with the technical debt, which gives you the red, green, refactor cycle of test driven development. When most people start writing regression tests, they start with a codebase with one test, does it compile? Then they tend to work from user interface and end to end tests, having lots of trouble because such legacy code is not designed with testing in mind, and thus is often either hard, fragile or just plain impossible to add. This leads to a lot of opposition to testing. The solution to this is to teach people what real unit tests are before you add the regression testing requirement.
    1