Explication simple de l'intégration continue


32

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.

entrez la description de l'image ici

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

3
oO Votre service marketing utilise Subversion? Tenté de voter pour fermer comme "Too Localized" ... ;-)
Jeroen

@ Jeroen Oui, vraiment, pour les fichiers sur le site. Je leur ai fait un beau gros bouton rouge sur une page Web qui dit «Fais-le» pour mettre à jour Subversion sur le serveur. :)
icc97

Réponses:


27

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é.


1
L'intégration continue se préoccupe de l'état de la construction, mais aussi des tests.
Quentin Pradet

1
et le déploiement, il ne suffit pas de compiler et d'exécuter des tests, mais vous devez également envoyer les fichiers binaires à un environnement afin qu'il puisse également être testé par des personnes (ou des outils automatisés).
gbjbaanb

1
Depuis que la question demandait une explication simple , j'ai omis de nombreux détails (la plupart du temps spécifiques à un projet / à une équipe) pouvant aller dans un système d'infrastructure de confiance.
c_maker

Est-ce que cela dépend du développement piloté par les tests? Le code qui compile n'est pas toujours un code qui fonctionne correctement? Si les tests échouent lorsque le code n'est pas prêt, comment le système CI peut-il savoir si le code a été réellement intégré?
mowwwalker

1
@ user828584: Dans ma réponse, j'implique que "test" fait partie d'une construction. De plus, TDD est différent des tests de vérification de la qualité. En tant qu'effet secondaire du TDD, vous aurez des tests bien écrits, mais vous pouvez avoir des tests sans faire de TDD du tout.
c_maker

33

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.


4
+1 pour l'aborder du point de vue des avantages qu'il procure.
Poke

17

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.


2
Nous avions un scénario similaire dans lequel nous avions mis à niveau une application personnalisée construite avec SP 2003 vers SP 2007. À l’aide de VSS (oui, VSS :), chaque développeur a extrait une partie de son fichier, codée pendant une semaine et deux, puis intégrée notre code, boom, que lorsque le problème a commencé depuis notre code a considérablement dévié. Nous avons résolu le problème de l'intégration pendant un mois et le projet a loué un hôtel pour accueillir ceux qui vivent très loin les jours de semaine. Ce jour-là, j'ai appris à intégrer le code quotidiennement :-)
OnesimusUnbound

@OnesimusUnbound Je me souviens d'être passé de VSS à Clearcase ... du pan au feu. Des années plus tard, après être retourné dans la même entreprise pour prendre un verre, je me souviens de quelqu'un qui se moquait de son collègue développeur en mentionnant ce nouveau contrôle de code source appelé "Git", "Pourquoi avons-nous besoin d'un autre système de contrôle de code source ??".
icc97

1
Merci - j'ai eu du mal à comprendre CI auparavant simplement parce que je ne savais pas quelle était l'alternative
Rhys

Intéressant. Pour moi, cela ressemble plus à comparer l'IC à la cascade. Mais vous pouvez utiliser une méthodologie sans cascade qui évite ces problèmes (comme le développement itératif) et ne pas utiliser de CI.
Dan Moulding

@DanMoulding Si je suis agile et itératif et que je ne fais pas partie d'un projet plus vaste qui n'est pas intégré à ce que fait quelqu'un d'autre, je ne fais pas de CI. Heck, vous pouvez cascade et CI. Tout concevoir, tout coder, tout tester si vous voulez - si tout le monde utilise les dispositions de code / schéma / fichier de tous les autres tout le temps, il s'agit d'un élément de configuration même si vous utilisez une cascade. Le lien est que sans CI, vous vivez et vous mourez de BDUF, car c’est votre seul espoir (et c’est un vif espoir) d’avoir une phase d’intégration d’une durée raisonnable. L'adoption de CI nous a permis de lâcher BDUF.
Kate Gregory
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.