Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
The term 'Continuous Integration' originated with the Extreme Programming development process, as one of its original twelve practices.
Continuous Integration assumes a high degree of tests which are automated into the software: a facility I call self-testing code.
In general you should store in source control everything you need to build anything, but nothing that you actually build. Some people do keep the build products in source control, but I consider that to be a smell - an indication of a deeper problem, usually an inability to reliably recreate builds.
I'll elaborate my earlier rule of thumb: anyone should be able to bring in a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine.
Материалы
- Fawler article
- WIKI article
The term 'Continuous Integration' originated with the Extreme Programming development process, as one of its original twelve practices.
Continuous Integration assumes a high degree of tests which are automated into the software: a facility I call self-testing code.
In general you should store in source control everything you need to build anything, but nothing that you actually build. Some people do keep the build products in source control, but I consider that to be a smell - an indication of a deeper problem, usually an inability to reliably recreate builds.
I'll elaborate my earlier rule of thumb: anyone should be able to bring in a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine.
Материалы
- Fawler article
- WIKI article
