Continuous Integration读书笔记

引言：

 1。An important part of any software development process is getting reliable builds of the software.
 2。It stresses a fully automated and reproducible build, including testing, that runs many times a day. This allows each developer to integrate daily thus reducing integration problems.
内容：
   A fully automated process that allows you to build several times a day is both achievable and well worth the effort.

There are several parts to making an automated daily build work.
     1.Keep a single place where all the source code lives and where anyone can obtain the current sources from (and previous versions)
    2.Automate the build process so that anyone can use a single command to build the system from the sources
    3.Automate the testing so that you can run a good suite of tests on the system at any time with a single command
    4.Make sure anyone can get a current executable which you are confident is the best executable so far.

The Benefits of Continuous Integration
    makes a fundamental shift to the whole development pattern
    it removes sessions where people spend time hunting bugs where one person's work has   stepped on someone else's work without either person realizing what happened.
    With continuous integration the vast majority of such bugs manifest themselves the same    day they were introduced.
    Continuous Integration can slash the amount of time spent in integration hell, in fact   it can turn hell into a non-event.

The More Often the Better
    Done well, more frequent integration should be painless and you end up spending much   less time carrying out the integration
    Most of integration can, and should, be done automatically.
    With an automated process like this, you can build as frequently as you like. The only   limitation is the amount of time it takes to do the build.

What Is a Successful Build?
   We are pretty aggressive about what we mean by a successful build.
     All the latest sources are checked out of the configuration management system
     Every file is compiled from scratch
     The resulting object files (Java classes in our case) and linked and deployed for    execution (put into jars).
     The system is started and suite of tests (in our case, around 150 test classes) is run    against the system.
     If all of these steps execute without error or human intervention and every test    passes, then we have a successful build

Single Source Point
     In order to integrate easily, any developer needs to be able to get a full set of   current sources easily.
     Anyone should be able to bring a clean machine, connect it to the network, and with a   single command bring down every source file that's needed to build the system under   development.
     Try to ensure everything is under a single source tree in the configuration management   system.

Automated Build Scripts
    Tests need to be run automatically.
   

Self-Testing Code
    XP divides tests into two categories: unit tests and acceptance (also called functional) tests.
    All of the XP-style unit tests are in the BVT.
    The basic principle is that when developers are writing code they also write tests for that code. When they complete a task, not just do they check in the production code, they also check in the tests for that code. Those that follow XP closely use the test first style of programming: you shouldn't write any code until you have a failing test. So if you want to add a new feature to the system, you first write a test that will only work if the feature is there, then you make that test work.
    Another important part of self-testing is to improve the quality of tests with feedback - a key value of XP.
    Furthermore this test should lead you to think of other tests that need to be written to strengthen the BVT.

The Master Build
    We've found that having a master build procedure brings the team together and makes it easier to find integration problems early.
   

Checking in
    The most important part of that rhythm is that they integrate regularly.
    Before starting on a new task, developers should first sync with the configuration management system. This will mean that their local copies of the sources are up to date. Writing code on top of out-of-date sources only leads to trouble and confusion.

Summing up
    Developing a disciplined and automated build process is essential to a controlled project. Many software gurus say that, but we've found that it's still a rarity in the field.
    The key is to automate absolutely everything and run the process so often that integration errors are found quickly. As a result everyone is more prepared to change things when they need to, because they know that if they do cause an integration error, it's easy to find and fix. Once you have these benefits, you'll find they are such that you'll kick and scream before you give them up.

呵呵!没想到那么多!有空翻译一遍!

转载于:https://www.cnblogs.com/xiexing1986/archive/2005/03/18/121478.html