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:
- 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.
- Assignez 3 développeurs, ou 3 équipes indépendantes de développeurs, aux 3 pièces
- 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.