Tout d’abord, je voudrais m’excuser auprès des F4 qui en voyant le mot “intégration” ont sauté de joie en pensant que j’allais leur présenter une nouvelle technique pour calculer une intégrale, dans le style de l’intégration par parties.
Je voudrais aussi présenter mes excuses à tous les ZZ qui ont cru que j’allais proposer de faire un WEI qui dure toute l’année 
Alors, c’est quoi l’intégration continue ?
Il s’agit d’une méthode de développement ayant pour but de s’assurer en permanence de la qualité du code se trouvant sur le gestionnaire de sources (CVS, SVN, git…).
Dans la pratique, on va mettre en place un serveur chargé de compiler les sources et de produire un nouveau package/setup/installeur à chaque modification de code publiée sur le gestionnaire de sources. En cas d’échec, les développeurs sont alertés (par mail, notification dans la barre des tâches…) afin de corriger le problème immédiatement.
Ça compile donc ça marche !
Hum, malheureusement pas vraiment 
Évidemment on ne pourra jamais remplacer les tests faits manuellement (par le développeur, puis par le fonctionnel, puis par le client), mais certains peuvent être automatisés : les tests unitaires.
Ils permettent de valider le bon fonctionnement d’un composant. Par exemple si on a une fonction Day NextDayOfWeek(Day day) chargée de retourner le jour suivant, on pourra vérifier automatiquement que NextDayOfWeek(sunday) renvoie bien monday.
En cas d’échec d’un test, on considère alors qu’il y a échec de l’intégration et les développeurs doivent être alertés.
Afin de s’assurer de la qualité du code, d’autres outils peuvent être utilisés en complément des tests unitaires :
-la couverture de code permettant de mesurer la quantité de code couvert par les tests unitaires et donc de détecter les méthodes non testées.
-l’analyse statique de code qui vérifie le code sans l’exécuter. Ils permettent par exemple de vérifier les normes de nommage, la quantité de commentaires, la taille des méthodes/classes/fichiers…
C’est quoi l’intérêt ?
Je ne doute pas que le geek en toi ne trouve pas ça trop beau, trop classe 
Mais il va falloir réussir à convaincre votre commercial qu’il faut acheter un nouveau serveur. Pour moi le principal avantage est de pouvoir s’assurer que le code compile sur n’importe quelle machine. En effet, il est fréquent qu’un code qui compile/marche sur la machine d’un développeur ne fonctionne que sur cette machine à cause d’une référence à une bibliothèque dont il est le seul à disposer (ou à avoir installé à un endroit précis).
On évite donc le stress de dernière minute, le jour de la livraison, lorsqu’on n’arrive plus à compiler une partie du code 
Un autre avantage est la possibilité d’avoir un versionning très précis des binaires livrés et donc de savoir exactement à quelle version du code source correspond le programme (buggué) qui tourne chez le client.
Concrètement, il y a besoin de quoi ?
-Un serveur (hardware) dédié à ça pour avoir une compilation qui reste rapide.
-Un serveur (logiciel) d’intégration continue : cruisecontrol, cruisecontrol.net, hudson…
-Un framework de tests unitaires : junit, nunit, mstest…
-Éventuellement, des programmes de tests statiques (fxcop, gendarme, coverity…) et de couverture de code (partcover, ncover, jcover…)
Pour finir, je vous invite à lire cet article de Martin Fowler qui présente en détail tous les aspects de l’intégration continue, notamment au niveau des bonnes pratiques que doivent respecter les développeurs.
A noter que ces pratiques sont devenues un “standard” pour n’importe quelle SSII de taille moyenne qui compte rester sur le marché plus de 10 jours. Probablement parce que c’est efficace, que ça assure vraiment un certain minimum de qualité, et parce que les clients savent maintenant que ces choses existent, donc les exigent.
SVN permet, via des ‘hook’, d’automatiser l’application de process avant ou après un commit. De cette manière, on peut en pre-commit lancer tout un tas de “valideurs” (syntaxe du code, code coverage, tests fonctionnels, etc). En cas d’échec, on ne prend pas le code du comitter. Si le commit s’effectue par contre, on l’ajoute automatiquement dans un log sur un Trac, et on schedule une compilation automatique via par exemple, BuildBot.
Tout ça pour dire que si ça peut paraitre vaste à mettre en place, et très chronophage au quotidien, en fait ça ne l’est pas tant que ça si c’est bien fait au départ : tout est ensuite industrialisé et ne change pas vraiment la manière de travailler des développeurs.
ça me rappelle des souvenirs de stage en SSII tout ça. Où l’on faisait de l’intégration continue, et dès qu’un mec “commitait”, tout le monde recevait un mail si jamais ça ne compilait pas.
Et quand tu travailles avec des gens en offshore qui ne savent pas que ce système est en place et qui committent à tire-larigot avec un code truffé d’erreurs ben ça fait beaucoup de mails, surtout si on a mal paramétré le truc et que ces gens ne reçoivent pas les dits-mails.
Autre point faible : deux personnes qui committent avant une recompilation (si elle est programmée toutes les dix minutes par exemple), si c’est la première personne qui a “foutu la merde” c’est la deuxième qui prend (enfin ça a p-e changé depuis).
Mais n’empêche ça reste vachement pratique quand on développe avec des retours clients fréquents (qui a dit méthodes agiles?).
@Alexandre : Normalement, le serveur prend comme responsable toute les personnes qui ont commité entre le dernier build réussi et le build en l’échec.
En générale, le matériel et le processus ne suffit pas, il faut aussi sensibiliser les équipes a l’utiliser a bon escient sinon, ils peuvent prendre ce processus comme une contrainte plus que comme une aide. Il arrive que certaines équipes cassent un build, l’ignorent volontairement et se lâchent (plus de vérifiaction de code, plus de tests unitaires a faire, …).
JetBrains propose une solution intéressante pour éviter de casser le build et permettre d’avoir un vcs clean avec la notion de commit pré-testé (http://www.jetbrains.com/teamcity/delayed_commit.html). En gros, on bypass le vcs et on envoie directement au serveur le code a tester. Si le build fonctionne, il est commité par le serveur, si il échoue, il est signalé au développeur et il ne va jamais aller jusqu’au commit (sauf si le développeur est un boulet).
Une alternative est l’utilisation de vcs décentralisé. Chaque développeur possède sa propre branche et le serveur build toute les branches de chaque développeur. Si le build est vert pour la branche, on peut merger sur le master. Mais je n’ai encore jamais vu d’entreprise conséquente utiliser des vcs décentralisé…