Explication simple de l'intégration continue

Comment définiriez-vous l'intégration continue et quels composants spécifiques un serveur CI contient-il?

Je souhaite expliquer à quelqu'un du service marketing ce qu'est l'intégration continue. Ils comprennent le contrôle de la source - c'est-à-dire qu'ils utilisent Subversion. Mais j'aimerais leur expliquer correctement ce qu'est l'IC. L' article de Wikipédia ne le définit jamais correctement. L' article de Martin Fowler ne donne que ce qui suit: il s'agit essentiellement d'une tautologie suivie d'une explication vague de "l'intégration":

L’intégration continue est une pratique de développement logiciel dans laquelle les membres d’une équipe intègrent leur travail fréquemment, chaque personne s’intégrant au moins quotidiennement, ce qui conduit à de multiples intégrations par jour. Chaque intégration est vérifiée par une construction automatisée (y compris un test) pour détecter les erreurs d'intégration aussi rapidement que possible.

Mise à jour : Je leur ai envoyé cette image, je ne pouvais pas en trouver une plus simple.

Mise à jour 2 : Commentaires du responsable du marketing (pour le moment où il y avait 3 questions):

En fait, j'aime bien les 3 réponses - pour différentes raisons. J'ai envie de me connecter juste pour les remercier tous!

Évidemment il ne peut pas - alors merci en son nom :)

Mise à jour 3 : j'ai compris en consultant l'article de Wikipedia qu'il contenait les principes qui, lorsque vous prenez juste les titres, constituent une bonne liste:

1. Maintenir un référentiel de code
2. Automatiser la construction
3. Faire la construction auto-test
4. Tout le monde s'engage au quotidien chaque jour
5. Chaque commit (à la ligne de base) doit être construit
6. Gardez la construction rapide
7. Test dans un clone de l'environnement de production
8. Facilitez l'obtention des derniers livrables
9. Tout le monde peut voir les résultats de la dernière version
10. Automatiser le déploiement

Lorsque quelqu'un modifie les fichiers qui composent le logiciel, puis tente de les archiver (en d'autres termes, tente d' intégrer les modifications dans le code du produit principal), vous voulez vous assurer que le logiciel peut toujours être construit avec succès.

Il existe généralement un système externe, appelé serveur de configuration , qui périodiquement ou à chaque modification, récupère les fichiers source du contrôle de version et tente de générer le produit (compile / test / package). Si le serveur de CI peut réussir à construire, les modifications ont été intégrées avec succès.

Le serveur CI doit également être en mesure de diffuser si la construction échoue ou réussit. Par conséquent, des systèmes comme Jenkins (l’un des serveurs CI les plus utilisés de nos jours) disposeront de moyens pour envoyer des courriels / textes ainsi qu’une interface Web semblable à un tableau de bord avec une interface Web. un tas d'informations sur les versions actuelles et passées, qui a archivé le code, quand quelque chose s'est cassé, etc. (Sur votre image ci-dessus, ce serait le mécanisme de feedback .)

L'IC est important, car il garantit que vous avez un produit qui fonctionne. Ceci est important pour tous les développeurs qui travaillent sur le produit logiciel ainsi que pour toutes les personnes qui souhaitent avoir accès aux versions quotidiennes du produit logiciel, telles que le contrôle qualité.

J'imagine que pour votre service marketing, le fonctionnement de CI n'est pas important , mais ce que cela signifie pour les nouvelles versions de votre logiciel .

Dans l’idéal, CI signifie que vous pouvez produire chaque jour une nouvelle version de votre logiciel potentiellement publiable , prête à être présentée ou vendue à votre client, moyennant l’ajout de nouvelles fonctionnalités, fonctionnalités ou corrections de bugs. Cela ne signifie pas que vous devez livrer la nouvelle version tous les jours, mais vous pouvez le faire si vous le souhaitez.

Par exemple, si vous envisagez de publier officiellement un nouvel ensemble de fonctionnalités pour la version "2015" de votre logiciel et que certaines parties de cet ensemble de fonctionnalités sont déjà codées et intégrées aujourd'hui, les responsables marketing peuvent utiliser la version actuelle de votre logiciel. logiciel et montrez-le - plus ou moins en toute sécurité - à la prochaine conférence en 2013. Sans CI, ils devaient demander à votre équipe de geler le code non planifié, chaque membre de l’équipe devait intégrer la fonctionnalité à moitié cuite sur laquelle il travaillait. produits, ils risquent de ne pas disposer de suffisamment de tests automatiques et devinez ce qui se passera à la conférence - la "version alpha" de votre version 2015er aura un risque beaucoup plus élevé de planter, en particulier lorsque les nouvelles fonctionnalités seront démontrées.

Vous ne pouvez pas savoir ce que c'est, à moins de savoir ce que nous faisions auparavant. Imaginez un système en 3 parties. Il existe une interface utilisateur qui collecte les données et les met dans la base de données. Il existe un système de reporting qui établit des rapports à partir de la base de données. Et il existe une sorte de serveur qui surveille la base de données et envoie des alertes par courrier électronique si certains critères sont remplis.

Il y a longtemps, cela serait écrit comme suit:

1. Convenez du schéma de la base de données et des exigences - cela prendrait des semaines car il devait être parfait car vous verrez bientôt pourquoi.
2. Assignez 3 développeurs, ou 3 équipes indépendantes de développeurs, aux 3 pièces
3. Chaque développeur travaillerait sur son morceau et le testerait en utilisant sa propre copie de base de données, pendant des semaines ou des mois.

Pendant ce temps, les développeurs n’exécutaient pas le code de l’autre, ni n’essayaient d’utiliser une version de la base de données créée par le code de quelqu'un d’autre. Le rédacteur du rapport voudrait juste ajouter un tas d’exemples de données. Le rédacteur d'alerte ajouterait des enregistrements qui simuleraient des événements de rapport. Et l'auteur de l'interface graphique examinerait la base de données pour voir ce que l'interface graphique avait ajouté. Au fil du temps, les développeurs se rendraient compte que la spécification était erronée, par exemple en ne spécifiant pas d'index ou en ayant une longueur de champ trop courte et en "corrigeant" cela dans leur version. Ils pourraient en informer les autres, qui pourraient agir, mais habituellement, ces choses figureraient sur une liste pour plus tard.

Lorsque les trois parties ont été entièrement codées et testées par leurs développeurs, et parfois même testées par les utilisateurs (leur montrant un rapport, un écran ou une alerte par courrier électronique), la phase "d'intégration" est lancée. Cela a souvent été budgétisé à plusieurs mois mais irait quand même. Ce changement de longueur de champ par dev 1 serait découvert ici et exigerait que les devs 2 et 3 effectuent d’énormes modifications de code et éventuellement des modifications d’interface utilisateur. Cet indice supplémentaire causerait ses propres ravages. Etc. Si un utilisateur demandait à un des développeurs d'ajouter un champ et le faisait, le moment serait venu pour les deux autres de l'ajouter également.

Cette phase était brutalement douloureuse et pratiquement impossible à prédire. Alors les gens ont commencé à dire "nous devons nous intégrer plus souvent". "Nous devons travailler ensemble depuis le début." "Quand l'un de nous pose une demande de changement [c'est ce dont on a parlé alors], les autres doivent le savoir." Certaines équipes ont commencé à faire des tests d'intégration tout en continuant à travailler séparément. Et certaines équipes ont commencé à utiliser le code et la sortie des autres tout le temps, dès le début. Et cela est devenu l'intégration continue.

Vous pensez peut-être que j'exagère cette première histoire. Une fois, j’ai travaillé pour une entreprise où mon contact m’a rongé pour avoir enregistré du code qui présentait les défauts suivants:

• un écran sur lequel il ne travaillait pas avait un bouton qui ne faisait rien encore
• aucun utilisateur n'avait signé la conception de l'écran (couleurs et polices précises; l'existence de l'écran, ses capacités et les boutons présents dans la spécification de 300 pages.)

C'était son opinion que vous ne mettez pas de choses dans le contrôle de source jusqu'à ce que ce soit fait. Il effectuait généralement une ou deux vérifications par an. Nous avons eu un peu de différence de philosophie :-)

En outre, si vous avez du mal à croire que des équipes seraient déconnectées autour d'une ressource partagée telle qu'une base de données, vous ne croirez pas (mais c'est vrai) que la même approche a été adoptée pour le code. Vous allez écrire une fonction que je peux appeler? C'est génial, allez-y et faites cela, je vais simplement coder ce que j'ai besoin entre-temps. Des mois plus tard, je vais "intégrer" mon code pour qu'il appelle votre API et nous découvrirons qu'il explose si je passe null, je explose s'il renvoie null (et cela se produit souvent), il renvoie des éléments trop volumineux. pour moi, il ne peut pas gérer les années bissextiles et mille autres choses. Travailler de manière indépendante puis avoir une phase d'intégration était normal. Maintenant, cela ressemble à de la folie.