Automatisation de construction vs automatisation de déploiement vs intégration continue

Je veux devenir plus efficace et je veux utiliser efficacement les outils ops.

Dans cet esprit, je voulais en savoir plus sur l'intégration continue, mais il semble qu'il y ait beaucoup de choses différentes à ce sujet.

Je travaille actuellement avec des combinaisons Jetbrains dans mon travail (IntelliJ, WebStorm ...), donc je voulais continuer à les utiliser, et je voulais utiliser TeamCity qui semblait être un excellent outil avec de nombreux plugins pour une intégration continue.

Mon problème est que je ne sais pas quelles sont les différences entre:

• automatisation du bâtiment (TeamCity est ce genre de logiciel): Je sais que nous pouvons construire notre application avec un référentiel VCS distant et c'est génial, mais quel est l'objectif principal de cela? Quel type d'informations est important lors de cette opération? En fait, je sais déjà si mon logiciel se construit ou non localement, et mes coéquipiers aussi. Alors, quel est l'objectif de l'utiliser sans déployer d'automatisation?

• déployer l'automatisation (TeamCity ne semble pas le faire facilement)

• intégration continue (qui semble être une conjonction des deux ci-dessus)
• livraison continue (qu'est-ce que c'est exactement? pourquoi est-ce différent de l'intégration continue?)

Pouvez-vous m'aider à comprendre un peu plus cela?

Wikipedia donne d'assez bons résumés de la plupart de ces termes. Voici mon point de vue sur eux:

• L'automatisation de la construction automatise la façon dont le logiciel est construit au lieu d'appeler manuellement le compilateur. Cela serait accompli via des outils tels que par exemple Make ou Ant .

• L'automatisation du déploiement consiste à prendre votre logiciel intégré et à le déployer ou à l'installer sur un système de test ou de production.

• L'intégration continue signifie qu'un processus automatisé crée votre logiciel en continu pendant que les développeurs archivent le code et exécutent des tests unitaires pour s'assurer que le code fonctionne toujours. Par exemple, toutes les 15 à 30 minutes, un serveur peut se réveiller, analyser VCS pour de nouveaux enregistrements, puis mettre à jour et créer le projet si des modifications ont été apportées. En plus d'effectuer des étapes de compilation, c'est également une excellente occasion d'exécuter des tests unitaires automatisés et des contrôles de qualité du code .

• La livraison continue est une combinaison de tous les concepts précédents où les versions logicielles sont également déployées sur un système de test, éventuellement avec des tests effectués et des rapports générés.

À tout le moins, vous devez avoir une automatisation de construction, c'est-à-dire un script de construction en quelque sorte. Cela vous permet de cliquer sur un bouton ou d'émettre une commande pour créer votre projet. L'avantage est de réduire les erreurs des étapes exécutées manuellement. Les environnements de construction complexes peuvent impliquer la génération de code (pensez aux DAO à partir des configurations , du code d'interface tel que JAXB ), la compilation du code, son empaquetage, la personnalisation des métadonnées, etc. Avec beaucoup de choses à faire, vous avez besoin d'une liste de contrôle: pourquoi ne pas faire votre script de construction et utiliser un outil pour l'exécuter? Il réduit les erreurs et assure la cohérence.

Ensuite, c'est CI: c'est vraiment bien d'avoir mais pas strictement requis. Il aide à identifier les problèmes de construction tôt. Si plusieurs développeurs archivent du code tout au long de la journée et ne synchronisent peut-être pas leurs propres espaces de travail en permanence, il y a un risque que leurs modifications interfèrent les unes avec les autres. Je fais référence spécifiquement aux erreurs de code statiques, pas aux conflits de contrôle de version. Un serveur de build CI atténuera ce risque.

Enfin, nous avons les étapes de déploiement. L'idée ici est de gagner du temps et de réduire les erreurs de déploiement manuel de logiciels. Tout comme l'automatisation de la construction, il existe une centaine de façons de bousiller un déploiement logiciel. Personnellement, je suis resté tard au bureau pour résoudre les problèmes de déploiement manuel à de nombreuses reprises lorsque nous avons besoin d'un système fonctionnel pour les clients qui viennent sur place demain. L'automatisation de plusieurs systèmes présente plus de risques: au lieu qu'un seul système tombe en panne ou ait des erreurs étranges, nous en avons maintenant plusieurssystèmes qui peuvent mal tourner. Cependant, ce risque est beaucoup plus faible que quelqu'un qui manque une étape sur une liste de contrôle ou émet la mauvaise commande et gâche un déploiement. Si vous avez de la chance, vous pouvez simplement restaurer une sauvegarde de base de données et recommencer, si vous n'avez pas de chance, une erreur peut entraîner un dysfonctionnement du système. S'agit-il d'un défaut logiciel? Le technicien n'a-t-il pas correctement défini une configuration? Cela prend du temps à diagnostiquer, du temps que vous n'avez peut-être pas et du temps qui ne doit pas être dépensé si vous automatisez le processus.

• L'intégration continue consiste à fusionner tous les changements des développeurs en une ligne principale partagée plusieurs fois par jour. Cette pratique est maintenant si omniprésente qu'elle peut ne pas sembler importante, mais les équipes travaillaient traditionnellement sur des logiciels pendant des semaines, voire des mois, isolément. Le résultat fut "Integration Hell" lorsque des flux de travail séparés furent fusionnés. L'intégration continue est normalement utilisée avec les versions automatisées de la ligne principale partagée pour détecter les problèmes tôt, mais c'est plus sur les validations fréquentes et le flux de travail des développeurs que sur DevOps.

• Les builds automatisés sont utiles pour détecter les problèmes qui pourraient faire passer la build localement, mais échouer sur le serveur de build (par exemple, vous avez oublié d'archiver un fichier, les dépendances sur le serveur de build ne correspondent pas). Le fait que le serveur de build détecte ces problèmes signifie que vous pouvez les résoudre avant vos coéquipiers.

• La livraison continue implique le déploiement, l'exécution et les tests continus de votre logiciel. Bien que les builds automatisés garantissent que votre logiciel se construit réellement (et que les tests unitaires réussissent), cela ne signifie pas que vos scripts de déploiement fonctionnent toujours ou que votre logiciel fonctionne réellement de bout en bout. L'objectif de la livraison continue est de disposer d'une série de vérifications garantissant que la ligne principale reste dans un état adapté au déploiement en production.

• Le déploiement continu est la prochaine étape logique: déployer automatiquement chaque validation qui passe avec succès par le pipeline de livraison continue. Il y a plusieurs avantages à cette pratique, mais pour moi, l'idée principale ici est que les petits commissions fréquentes sont moins risquées.

Je recommande de lire ce livre pour plus d'informations:

• Livraison continue: versions de logiciels fiables grâce à l'automatisation de la construction, des tests et du déploiement

Teamcity comme la plupart des outils de construction n'est qu'une application centrale qui vous permet d'exécuter de nombreuses tâches différentes. Cela comprend l'exécution de builds comme les builds CI, les builds de version complète et cela vous permet d'effectuer des déploiements. Si vous utilisez teamcity pour appeler ant ou nant pour exécuter msbuild sur un fichier de solution, vous pouvez également appeler des scripts nant qui effectueront des déploiements. Cela peut nécessiter un peu de script mais ce n'est pas trop difficile.

Nous utilisons teamcity et bamboo pour les CI complets, les CI de base de données et nous déployons dans l'environnement INTegration. Nous utilisons ensuite teamcity pour les versions complètes et la création automatique de scripts de migration db. Ceux-ci sont archivés dans SVN via des jobs teamcity appelant aux scripts nant. Pour les déploiements, vous l'aurez deviné, nous utilisons teamcity pour appeler Nant pour effectuer des tâches de déploiement. Cela fonctionne bien car l'agent teamcity parle au serveur teamcity et l'agent peut exister sur l'un des serveurs dans un emplacement DMZ, ce qui aide à déplacer le code au-delà des pare-feu, etc. Donc, teamcity ou bamboo est tout ce dont vous avez besoin pour gérer l'ensemble du scénario .