Automatisation de la construction vs déploiement de l'automatisation 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 le principal objectif de cela? Quel type d'informations est important pour cela? 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:
Build automation automatise la construction du logiciel au lieu d'invoquer manuellement le compilateur. Cela serait accompli via des outils tels que par ex. Marque 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.
Intégration continue signifie qu'un processus automatisé construit votre logiciel en continu pendant que les développeurs archivent le code et exécutent des tests unitaires pour garantir le code fonctionne encore. Par exemple, toutes les 15 à 30 minutes, un serveur peut se réveiller, scanner VCS pour de nouveaux enregistrements, puis mettre à jour et construire 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 contrôles de qualité du code .
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 avez besoin d'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 lors de l'exécution manuelle des étapes. Les environnements de construction complexes peuvent impliquer la génération de code (pensez DAOs à partir de configurations, le code d'interface tel que [~ # ~] jaxb [~ # ~] ), la compilation de code, l'empaquetage , personnalisation des métadonnées, etc. Avec beaucoup de choses à faire, vous avez besoin d'une liste de contrôle: pourquoi ne pas faire de la liste de contrôle votre script de construction et utiliser un outil pour l'exécuter? Il réduit les erreurs et assure la cohérence.
Ensuite est CI: c'est vraiment bon 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 avons maintenant plusieurs systè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.
Intégration continue est la pratique de fusionner tous les changements de 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 ont été 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 entraîner le passage local de la build, 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 - le déploiement automatique de 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: