Qu'est-ce que l'intégration continue (CI) et en quoi est-elle utile? [fermé]

Quelqu'un peut-il m'expliquer le concept de l'intégration continue, comment cela fonctionne d'une manière facile à comprendre? Et pourquoi une entreprise devrait-elle adopter CI dans son flux de travail de livraison de code? Je suis développeur et mon entreprise (principalement l'équipe de build) utilise Team City. En tant que développeur, je vérifie toujours, mets à jour et valide le code sur SVN, mais je n'ai jamais vraiment eu à me soucier de TeamCity ou de CI en général. Je voudrais donc comprendre quelle est l'utilité de l'IC? Le CI fait-il partie des méthodologies Agiles?

L'intégration continue en bref signifie que vous enregistrez votre travail, vous le poussez vers le système de gestion des documents (SVN dans votre cas), tous les tests sont exécutés automatiquement (tests unitaires, d'intégration, fonctionnels, etc.) et l'application est compilée et préparée pour la livraison (c.-à-d. une image ISO est créée). L'intégration continue n'est pas la même chose avec la livraison continue. La livraison se fait toujours à différents moments. CI garantit que le produit pourrait être livré si nécessaire, rien de plus.

Chaque fois que quelque chose ne va pas, l'équipe reçoit une notification. Habituellement, à ce stade, tous les travaux sont interrompus et tous les efforts sont concentrés pour s'assurer que le produit est stable. Aucun push et commit ne se produit sur le référentiel alors que le système n'est pas vert.

CI garantit que le produit est toujours dans un état stable et peut potentiellement être livré à tout moment. Veuillez noter que stable ne signifie pas que la fonctionnalité est complète. Il peut également y avoir des fonctionnalités à moitié implémentées, mais le système peut être stable.

Le CI est généralement associé aux méthodologies Agiles, mais je ne connais pas personnellement l'historique exact du CI.

L'intégration continue signifie: l'intégration du code dans un produit qui fonctionne réellement et qui peut être testé se produit tout le temps , et non (comme c'était le cas auparavant) en tant qu'activité distincte tard dans le cycle de vie du développement.

Il nécessite que le processus de génération de l'application soit complètement automatisé, et une suite de tests automatisée, et un serveur qui construit l'état actuel du code et exécute la suite de tests dessus. Cela devrait se produire quotidiennement, ou même après chaque enregistrement de code.

L'avantage est qu'il y a un retour immédiat sur les changements de code qui provoquent des erreurs de compilation (par exemple parce que le développeur n'a pas réussi à archiver toutes les modifications ou utilise un composant non présent dans le système de construction) ou des échecs de cas de test. Cela rend ces erreurs beaucoup plus faciles à corriger, car vous savez quel changement les a causées et la personne responsable a encore de nouveaux souvenirs de ce qu'elle a fait.

Sans CI, toutes ces erreurs émergent ensemble en même temps pendant la phase d'intégration, ce qui les rend extrêmement difficiles à corriger.

Vous pourriez avoir un certain style en développement: vous extrayez, codez, compilez, vérifiez, maudissez, modifiez, compilez, applaudissez, validez. Vous ne validez que le code de travail, peut-être même de manière moins granulaire, comme à la fin de votre journée de travail ou lorsqu'une fonctionnalité est terminée. Vous vérifiez vos dépendances chaque fois que vous importez des bibliothèques d'API.

Lorsque vous commencez à coder avec d'autres et lorsqu'il existe des dépendances mutuelles, il est logique d'adopter une intégration continue. Tout simplement parce que vous ne pouvez pas connaître l'impact des modifications sur les personnes qui dépendent de votre code et que vous ne recevez aucun signal chaque fois que vous devez mettre à jour vos importations.

Ainsi, lorsque l'un de vous apporte une modification, les deux projets doivent être construits et testés ensemble, c'est-à-dire exécutés par rapport à l'autre API, construits et testés avec la nouvelle bibliothèque, etc. Ces tests, votre code et celui de quelqu'un d'autre, sont appelés tests d'intégration.

Pourquoi continu? Parce qu'il est plus facile de déléguer la coordination de l'intégration à un système qui teste une build propre chaque fois qu'il y a un changement dans l'une ou l'autre base de code que d'organiser tout cela pour un humain. Le système peut évoluer.

L'intégration continue comporte deux aspects.

1. La stratégie de contrôle des sources de développement garantit que les développeurs sont en mesure d'intégrer en permanence leur travail en cours avec le code stable des autres développeurs.
2. La construction et le test automatique du code source déclenché par une validation du contrôle de code source

Le point 1 est critique. C'est la décision de rendre les fusions que les développeurs effectuent réellement fréquentes et de petite taille qui rend les fusions beaucoup plus susceptibles d'être réussies.

Le point 2 est les outils et le cadre nécessaires pour permettre au point 1 de se produire en toute sécurité, identifiant rapidement les fusions qui ont échoué en cassant le code existant.

Est-ce utile?

Incroyablement. En tant que développeur travaillant sur un projet, il vous permet de passer la plupart de votre temps à vous concentrer sur ce que vous faites, sans vous soucier du travail simultané du reste de l'équipe. Lorsque votre travail actuel est terminé, vous publiez ensuite vos modifications au reste de l'équipe et au cours des prochaines heures, elles fusionnent toutes vos modifications dans leur travail actuel.

Sans cela, les développeurs font de grosses fusions. Ils prennent généralement plusieurs jours de leur travail et doivent le fusionner avec toutes les modifications apportées par le reste de l'équipe en une seule fois. Lorsqu'une fusion se détériore sensiblement, l'autre développeur aura probablement déménagé sur un autre travail et commencera à oublier les détails pour aider à décoller le désordre de fusion. Pire encore, sans la construction et les tests continus, tant que le code est compilé, les bogues de fusion peuvent apparaître dans le code et ne seront pas détectés tant que les tests (ou les clients) ne les auront pas trouvés.

CI est utile lorsque vous avez:

• Compilation de code
• Ensemble réel de tests
• Rapports, basés sur votre code source (couverture du code, violence aux normes du code, etc.)
• Routine que vous effectuez périodiquement, une fois le code compilé avec succès

La liste peut être poursuivie.