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 veux expliquer à quelqu'un du service marketing ce qu'est l'intégration continue. Ils comprennent le contrôle de source - c'est-à-dire qu'ils utilisent Subversion. Mais je voudrais leur expliquer correctement ce qu'est CI. Le article Wikipedia ne le définit jamais correctement, le article Martin Fowler ne donne que ce qui suit, qui est essentiellement une tautologie suivie d'une vague explication de 'l'intégration':
L'intégration continue est une pratique de développement logiciel où les membres d'une équipe intègrent fréquemment leur travail, généralement chaque personne s'intègre au moins quotidiennement - ce qui conduit à plusieurs 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 le plus rapidement possible.
Mise à jour : Je leur ai envoyé cette image, je n'ai pas trouvé de plus simple.
Mise à jour 2 : Retour d'information du responsable marketing (pour le moment où il y avait 3 questions):
J'aime en fait les 3 réponses - pour différentes raisons. J'ai envie de me connecter juste pour les remercier tous!
De toute évidence, il ne peut pas - alors merci en son nom :)
Mise à jour 3 : J'ai réalisé en regardant l'article Wikipedia qu'il contient les principes qui, lorsque vous prenez juste le rubriques, est une assez bonne liste:
- Maintenir un référentiel de code
- Automatisez la construction
- Faire l'auto-test de construction
- Tout le monde s'engage chaque jour sur la base de référence
- Chaque commit (à la ligne de base) doit être construit
- Gardez la construction rapide
- Test dans un clone de l'environnement de production
- Obtenez facilement les derniers livrables
- Tout le monde peut voir les résultats de la dernière version
- Automatisez le déploiement
Lorsque quelqu'un modifie les fichiers qui composent le produit logiciel, puis tente de les archiver (en d'autres termes, tente de intégrer les modifications dans le code produit principal), vous voulez vous assurer que le produit logiciel peut encore être construit avec succès.
Il existe généralement un système externe, appelé serveur CI, qui, périodiquement ou à chaque modification, récupérera les fichiers source du contrôle de version et tentera de créer le produit (compilation/test/package). Si le serveur CI peut réussir une génération, 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, de sorte que des systèmes comme Jenkins (l'un des serveurs CI les plus utilisés aujourd'hui) auront des moyens d'envoyer des e-mails/textes ainsi qu'une interface Web de type tableau de bord avec un tas d'informations sur les versions actuelles et passées, qui a archivé le code, quand les choses se sont brisées, etc. (Sur votre image ci-dessus, ce serait le mécanisme de rétroaction .)
L'IC est important, car il garantit que vous disposez en permanence d'un produit fonctionnel. 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, comme QA.
Je suppose que pour votre service marketing, il n'est pas important comment CI fonctionne , mais ce que CI signifie pour les nouvelles versions de votre logiciel .
CI signifie idéalement que vous pouvez produire une nouvelle version potentiellement libérable de votre logiciel chaque jour, prête à être présentée ou vendue à votre client, avec quelques nouvelles fonctionnalités, fonctionnalités ou corrections de bogues ajoutées. Cela ne signifie pas que vous devez livrer la nouvelle version tous les jours, mais vous pouvez si vous le souhaitez.
Par exemple, si un nouvel ensemble de fonctionnalités est prévu pour être officiellement publié 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 prendre la version actuelle de votre logiciel et le montrer - plus ou moins en toute sécurité - lors de la prochaine conférence maintenant en 2013. Sans CI, ils ont dû demander à votre équipe un gel de code imprévu, chaque membre de l'équipe a dû intégrer la fonctionnalité semi-cuite sur laquelle il travaille dans le produit, ils pourraient ne pas avoir suffisamment de tests automatiques prêts, et devinez ce qui se passera lors de la conférence - la "version alpha" de votre version 2015er aura un risque beaucoup plus élevé de planter, surtout lorsque les nouvelles fonctionnalités seront démontrées.
Vous ne pouvez pas savoir ce qu'est CI à moins de savoir ce que nous faisions. Imaginez un système en 3 parties. Il existe une interface utilisateur qui collecte des données et les place dans la base de données. Il existe un système de rapport qui crée 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 e-mail si certains critères sont remplis.
Il y a longtemps, cela serait écrit comme suit:
- Mettez-vous d'accord sur le schéma de la base de données et les exigences - cela prendrait des semaines, car il devait être parfait, car vous verrez bientôt pourquoi
- Assignez 3 devs, ou 3 équipes indépendantes de devs, aux 3 pièces
- Chaque développeur travaillerait sur sa pièce et testerait sa pièce en utilisant sa propre copie de base de données, pendant des semaines ou des mois.
Pendant ce temps, les développeurs ne s'exécuteraient pas le code de l'autre, ni n'essaieraient d'utiliser une version de la base de données qui avait été créée par le code de quelqu'un d'autre. Le rédacteur du rapport ajouterait simplement un tas d'exemples de données. Le rédacteur d'alerte ajouterait des enregistrements simulant des événements de rapport. Et le rédacteur de l'interface graphique regardait 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 d'une manière ou d'une autre, comme ne pas spécifier d'index ou avoir une longueur de champ trop courte, et "corriger" cela dans leur version. Ils pourraient dire aux autres, qui pourraient agir en conséquence, mais généralement ces choses seraient inscrites sur une liste pour plus tard.
Lorsque les trois parties étaient complètement codées et testées par leurs développeurs, et parfois même testées par les utilisateurs (en leur montrant un rapport, un écran ou une alerte par e-mail), viendrait alors la phase "d'intégration". Celui-ci était souvent budgétisé à plusieurs mois mais restait en suspens. Ce changement de longueur de champ par dev 1 serait découvert ici, et nécessiterait que les devs 2 et 3 fassent d'énormes changements de code et éventuellement des changements d'interface. Cet index supplémentaire ferait ses propres ravages. Etc. Si l'un des développeurs a été invité par un utilisateur à ajouter un champ et l'a fait, ce serait le moment pour les deux autres de l'ajouter également.
Cette phase a été brutalement douloureuse et pratiquement impossible à prévoir. Les gens ont donc commencé à dire "nous devons nous intégrer plus souvent". "Nous devons travailler ensemble depuis le début." "Quand l'un de nous soulève une demande de changement [c'est comme ça que nous parlions alors], les autres doivent le savoir." Certaines équipes ont commencé à faire des tests d'intégration plus tôt tout en continuant à travailler séparément. Et certaines équipes ont commencé à utiliser le code des autres et à produire 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 grondé pour avoir vérifié un code qui souffrait des défauts suivants:
- un écran sur lequel il ne travaillait pas avait un bouton qui ne faisait rien encore
- aucun utilisateur n'avait approuvé la conception de l'écran (couleurs et polices précises; l'existence de l'écran, ses capacités et les boutons qu'il comportait dans la spécification de 300 pages.)
C'était son avis que vous ne mettez pas des choses dans le contrôle de source jusqu'à ce que ce soit fait. Il faisait généralement un ou deux enregistrements par an. Nous avons eu une petite différence de philosophie :-)
De plus, si vous avez du mal à croire que des équipes seraient déconnectées autour d'une ressource partagée comme une base de données, vous ne croirez vraiment pas (mais c'est vrai) que la même approche a été adoptée pour coder. Tu vas écrire une fonction que je peux appeler? C'est super, allez-y et faites-le, je vais simplement coder en dur ce dont j'ai besoin en attendant. Des mois plus tard, j'intégrerai mon code pour qu'il appelle votre API et nous découvrirons qu'il explose si je passe null, je fais exploser s'il retourne null (et ça fait beaucoup) il retourne des choses trop grandes pour moi, il ne peut pas supporter les années bissextiles et mille autres choses. Travailler de façon autonome puis avoir une phase d'intégration était normal. Maintenant, cela ressemble à de la folie.