How would you define Continuous Integration and what specific components does a CI server contain?
I want to explain to someone in the marketing department what Continuous Integration is. They understand Source control – i.e. they use Subversion. But I'd like to explain to them properly what CI is. The Wikipedia Article never properly defines it, the Martin Fowler article only gives the following, which is basically a tautology followed by a vague explanation of 'integration':
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.
Update: I sent them this image, I couldn't find a simpler one.
Update 2: Feed back from the marketing chap (for the time when there was 3 questions):
I actually like all 3 answers – for different reasons. I feel like logging in just to thank them all!
Obviously he can't – so thanks on his behalf 🙂
Update 3: I've realised looking at the Wikipedia article that it does contain the principles which, when you take just the headings, is quite a good list:
- Maintain a code repository
- Automate the build
- Make the build self-testing
- Everyone commits to the baseline every day
- Every commit (to baseline) should be built
- Keep the build fast
- Test in a clone of the production environment
- Make it easy to get the latest deliverables
- Everyone can see the results of the latest build
- Automate deployment
Best Answer
When someone changes the files that make up the software product and then attempts to check them in (in other words, attempts to integrate the changes into the main product code) you want to make sure that the software product can still be successfully built.
There is usually an external system, called the CI server, that either periodically or on every change, will grab the source files from version control, and attempt to build the product (compile/test/package). If the CI server can successfully do a build, the changes have been successfully integrated.
The CI server also has to be able to broadcast if the build failed or succeeded, so systems like Jenkins (one of the most used CI server today) will have ways to send emails/texts as well as a dashboard-like web interface with a bunch of information about current and past builds, who checked-in code, when things broke, etc. (On your image above, this would be the Feedback Mechanism.)
CI is important, because it ensures that on a continuous basis, you have a working product. This is important for all the developers who are working on the software product as well as for all the people who want to have access to daily releases of the software product, like QA.