If you like the pragmatic programmer stuf, consider buying the book, see my blog for a book review.

If you like the pragmatic programmer stuf, consider buying the book :

Does this all sound as a lot work to you? Well, it is, at least the first time. Of course you are not the first to walk this way. There are a lot of tools? available and maybe even more books.

The image shows a number of important parts of continuous integration:

One step builds

With one step you must be able to execute a complete build, run the unit tests and create a deployable unit. Another term used in the mentioned book is CRISP builds :
Complete - No manual actions necessary to create a build and run tests
Repeatable - You should be able to recreate previous builds
Informative - If a build fails comments should be as obvious to find the problem
Schedulable - It must be possible to schedule a build on a certain interval or at a certain time
Portable - It should be to difficult to port the build to another machine

Scheduled builds

A scheduled build is not the same for every project. There are a few options:

• Every time a build is finished, start the next build.
• At a certain interval, every two hours or every day for example.
• Every time something is changed in the source Repository (a new checked in file)

Push button releases

At the push of a button you want to create a complete release, that means including documentation and installation files.

Installation and deployment

Installation and deployment must be automated as well, within an ideal situation, no manual interaction should be necessary to deploy your applicatiom.

Monitoring

Throughout all the steps you need to receive reports about a build, alerts when the build is broken, and when a new release is created, etc.

Continuous integration is widely discussed on the internet. Google gives about 70000 hits. Talking about it is not enough, you need to have a consistent appraoch over all your projects. In a few words, what does it mean. Continuous integration means you can create complete builds, unit test and deploy them continuously. On top of that, if your projects consists of multiple subprojects, integration makes sure continuously that all different components integrate with each other.

Why would you consider continuous integration? Start with an iterative development process. Create your components, finalize them and try to integrate them with each other. This can give you a lot of problems. Therefore you should start integrating your components much sooner, preferably continuously. That is what Continuous integration is about.

Explain the image

The following image is taken from the book http://www.pragmaticautomation.com/. The book has a very nice story at the beginning about Continous integration. If you are curious, go to the website and download the sample chapter.

The following image is taken from the book http://www.pragmaticautomation.com/.

http://www.gridshore.nl/pub/images/ContinuousIntegration.jpg

Another term used in this book is crisp builds :
Complete
Repeatable
Informative
Schedulable
Portable

Discuss Continuous Integration