Qu'est-ce qu'un bon processus de construction de CI?

https://stackoverflow.com/questions/102902

01-07-2019
|

Question

Qu'est-ce qui constitue un bon processus de construction d'EC?

Nous utilisons CI, mais le déploiement en production est-il même un objectif réaliste lorsque vous dépendez de plusieurs services et que d'autres applications peuvent également en dépendre.

Un bon processus de construction de CI est-il assez bon lorsqu'il est automatisé pour le contrôle qualité et manuel à partir de là?

La solution

Bien "ça dépend" :)

Nous utilisons notre système de CI pour:

construire & amp; test unitaire
déployer dans une seule boîte, exécuter des tests d'intégration et analyser le code
déployer dans un environnement de laboratoire
exécuter des tests d'acceptation dans un système de type prod
les constructions drop qui passent au code drop pour le déploiement de prod

Il s’agit d’un projet novateur d’une douzaine de services et de bases de données déployés sur plus de 20 serveurs, qui dépendaient également d’une demi-douzaine d’autres services "externes".

Vous utilisez un outil de CI pour déployer votre produit dans un environnement de production de manière réaliste? encore une fois ... "cela dépend"

Pourquoi voudriez-vous faire cela?

si vous avez le processus, vous pouvez annuler les modifications (et les restaurer) plus rapidement et plus souvent
moins de risques d'erreur humaine
vous pouvez tester la même stratégie de déploiement dans un environnement de test avant de passer en production et de résoudre les problèmes plus tôt

Certaines questions techniques que vous devez aborder avant de pouvoir répondre à cette question:

quelles sont les conditions de disponibilité de votre système - Êtes-vous autorisé à avoir un temps d'indisponibilité ou devez-vous le laisser fonctionner 24h / 24 et 7j / 7?
Avez-vous mis en place des processus de contrôle des modifications nécessitant une intervention / approbation humaine?
votre déploiement est-il suffisamment robuste pour que tout composant puisse revenir à un état connu en cas d'échec du déploiement?
votre système est-il conçu pour gérer différentes versions de services ou de clients au cas où un ou plusieurs déploiements de composants échoueraient (et que vous avez la restauration ci-dessus au dernier bien connu)?
le processus dispose-t-il des compétences nécessaires pour gérer un déploiement partiel dans lequel un composant ne peut pas gérer des versions mixtes de ses dépendances / clients?
comment gérez-vous le déploiement / les mises à niveau de la base de données?
avez-vous mis en place une surveillance afin que vous sachiez si quelque chose ne va pas?

Voici quelques liens récents sur automation et créer les outils dont vous avez besoin .

En définitive, plus votre système est complexe, plus il est difficile d’automatiser tout, mais cela ne signifie pas pour autant que ce n’est pas un objectif louable, il faut simplement plus d’efforts et de volonté pour le faire. de la connaissance des difficultés que vous allez rencontrer, des problèmes que vous devez prendre en compte (l'échec se produira ), des défis politiques liés à la construction d'infrastructures (par rapport à davantage de fonctionnalités du produit).

Maintenant, voici le grand secret ... les défis techniques sont difficiles mais non impossibles ... les défis politiques peuvent être insurmontables. Tout cela coûte de l’argent, que ce soit pour le développement ou pour l’achat de solutions tierces. Alors vraiment, pouvez-vous créer la solution à 1 000 $, 10 000 $, 100 000 $ ou 1 M $?

Quelle que soit la solution choisie, assurez-vous que l'automatisation est robuste en premier, complète en second lieu ... c'est-à-dire, assurez-vous de disposer d'une solution aussi robuste que possible pour obtenir un déploiement dans un environnement de test plutôt qu'une solution fragile déployée en production.

Autres conseils

Le CI n'est pas conçu comme un mécanisme de déploiement. Il est bon de laisser votre CI exécuter tout déploiement automatisé sur un serveur QA / Test, afin de garantir le bon fonctionnement de votre build, mais je n’utiliserais pas un système de CI comme Cruise Control ou Bamboo. de déploiement.

CI est destiné à la construction périodique de la base de code pour automatiser l'exécution de tests automatisés, la vérification de la base de code via une analyse statique et d'autres contrôles de cette nature.

Assurez-vous de bien comprendre l’idée qui sous-tend la construction d’un CI. CI signifie Continuous Integration et les constructions de CI sont vraiment conçues pour être des constructions à jeter qui sont effectuées lorsqu'un développeur enregistre le code dans le système de contrôle de la source (ou à un intervalle spécifié) pour s'assurer que les modifications les plus récentes n'enfreignent pas la base de code. (d’où l’idée d’intégrer en permanence les modifications à la base de code).

À cette fin, la technologie utilisée pour le processus de construction du serveur est en grande partie hors de propos par rapport à ce qui se passe réellement pendant la construction. Comme @pdavis l'a mentionné, la génération de CI doit compiler la base de code, exécuter une analyse de code (FxCop, StyleCop, Lint, etc.), exécuter des tests unitaires et une couverture de code, et exécuter toute autre analyse personnalisée à effectuer qui devrait avoir une incidence sur le concept. d'un " réussi " ou " échoué " construire.

Le déploiement automatique d'une génération de CI dans un environnement ne relève pas du contrôle d'un serveur de génération. Cela étant dit, vous pouvez toujours créer un projet distinct qui s'exécute sur le serveur de génération et qui gère le déploiement lorsqu'il détecte certaines conditions (telle qu'une génération réussie), mais cela doit toujours être fait de manière totalement indépendante.

Je commence un nouveau projet au travail que je suis vraiment impatient de voir. Nous en sommes toujours à la phase de conception initiale et venons tout juste de terminer l'architecture du système logique. Nous avons commandé de nouveaux serveurs pour les environnements de test et de transfert et nous mettons en place un système de construction à intégration continue (CI) basé sur Cruise Control ( http://cruisecontrol.sourceforge.net/ ) et MSBuild ( http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx ), qui est fondamentalement un port amélioré de ANT. Il semble que les fichiers de projet et de solution Visual Studio 2005 soient maintenant au format MSBuild. Cruise Control va automatiquement extraire la source de Visual Source Safe (ok, ce n’est pas Subversion mais nous pouvons en traiter), la compilant puis l’exécutant via fxCop ( http://www.gotdotnet.com/Team/FxCop/ ), nUnit ( http://www.nunit.org/ ), nCover ( http : //ncover.org/site/ ), et dernier mais pas louer Simian ( http://www.redhillconsulting.com.au/products/simian/ ). Cruise Control possède une très bonne interface Web permettant d'afficher tous les résultats compilés des différents outils et peut même afficher les modifications de code d'une génération à l'autre. Il garde également une trace de toutes les versions de l'historique. J'attends avec impatience le développement piloté par les tests et pense que ce type d'approche associé à nUnit / nCover devrait nous donner une assez bonne idée avant de mettre en œuvre des modifications que nous n'avons pas cassées. Il est également prévu d'incorporer un certain type de test d'interface utilisateur automatisé une fois que le projet sera suffisamment avancé. Selon l’outil, il suffit de l’installer sur le serveur de compilation et de l’appeler à partir de Cruise Control. Doux.

Un bon processus de CI aura une couverture de test unitaire complète ou presque complète. Tests unitaires Classes et méthodes de test, par opposition aux tests d'intégration, qui testent plusieurs parties du système. Lorsque vous configurez vos versions de CI, demandez-leur d'automatiser les tests unitaires. De cette façon, les builds CI peuvent être exécutés plusieurs fois par jour. Le nôtre doit fonctionner toutes les deux heures.

Vous pouvez utiliser des versions plus longues exécutées une fois par jour. Ceux-ci peuvent utiliser d'autres services et exécuter des tests d'intégration.

Je regardais une présentation de ThoughtWorks (créateurs de Cruise Control) et ils ont en fait abordé ce problème. Leur réponse est que le déploiement de NO est trop complexe pour être testé. Pourquoi? Sinon, vos clients deviennent vos testeurs, ce qui est exactement ce que vous ne voulez pas être.

Si vous avez une structure de déploiement complexe, configurez un serveur de visualisation. Faites-le prétendre être tous les systèmes auxquels vous devez parler. Ils peuvent toujours démarrer dans un bon état, car vous pouvez restaurer une image vierge.

Pour répondre à votre question initiale, un bon processus est celui qui permet la communication entre le référentiel et les développeurs. Si le référentiel est en mauvais état (code non compilant, tests ayant échoué, etc.), les développeurs le savent dès que possible, afin de pouvoir le corriger.

Plus un bogue est découvert, plus il est coûteux à corriger. Donc, les bugs doivent être découverts le plus tôt possible. C’est la motivation de CI.

Un bon IC doit s’assurer de prendre le plus de bugs possible. L’ensemble de l’application comprend du code (souvent en plusieurs langues), un schéma de base de données, des fichiers de déploiement, etc. Des erreurs dans l’une de ces erreurs peuvent être à l’origine de bogues. L’ÉI doit donc en exercer autant que possible.

CI ne remplace pas une discipline appropriée d’AQ. De plus, CI n’est pas forcément très complet le premier jour du projet. On peut commencer avec un processus simple de CI qui effectue une compilation de base & amp; tests unitaires initialement. Au fur et à mesure que vous découvrez plus de classes de bogues dans le contrôle qualité, vous devez adapter le processus CI pour essayer de détecter les futures occurrences de ces bogues. Cela peut également impliquer des vérifications statiques d’analyse de code, afin que vous puissiez mettre en œuvre des idéaux de codage et de conception cohérents dans toute la base de code.

Un bon processus de construction de CI est-il assez bon lorsqu'il est automatisé pour le contrôle qualité et manuel à partir de là?

Je pense que ce "manuel" le déploiement est utilisé lorsque les personnes ayant le rôle d'ingénieur de déploiement craignent que quelque chose après le déploiement ne tourne mal. Il n’a pas confiance en la fiabilité et la stabilité des outils de déploiement.

Cet exploit peut disparaître avec les tests de processus de déploiement automatisés sur un environnement de type prod. Il doit également tester un mécanisme de restauration après le déploiement.

Lorsque ces fonctions seront suffisamment testées, vous gagnerez en confiance en ce processus et en l'outil que vous utilisez.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow