Existe-t-il un outil CI qui ne garantit aucune régression dans le niveau de qualité des succursales?

10

Traditionnellement, les systèmes CI effectuent uniquement la surveillance des niveaux de qualité dans une branche d'intégration, en effectuant des vérifications d'assurance qualité sur la base de code où les modifications sont déjà validées, en surveillant les régressions et en envoyant des notifications pour une intervention humaine.

Mais lorsque ces régressions sont détectées, la branche a déjà eu des problèmes au moins depuis le début de la vérification de l'AQ respective et restera dans cet état (ou même s'aggravera!) Jusqu'à ce que tous les coupables soient identifiés, les réparations engagées et une nouvelle vérification de l'AQ confirme que le niveau de qualité de la succursale a été restauré. La branche peut être considérée comme bloquée pour un développement normal pendant tout ce temps.

Existe-t-il un outil CI capable d' empêcher de telles régressions de se produire, qui effectuerait des vérifications QA pré-validation et n'autoriserait les validations que lorsque la base de code mise à jour avec les validations respectives passerait également ces vérifications QA pré-validation, garantissant ainsi un minimum niveau de qualité de la succursale?

Mise à jour: l'hypothèse est que des vérifications d'AQ automatisées appropriées avec une couverture appropriée pour pouvoir détecter les régressions respectives sont disponibles pour être invoquées par le ou les outils CI.

Dan Cornilescu
la source
Je continue de m'interroger sur la bonne façon de comprendre cette question (et votre propre recommandation dans votre propre réponse). Si je remplaçais «surveiller» par «après les faits» et «empêcher» par «les empêcher de se produire», serait-ce plus ou moins la même question? De plus, vous pouvez peut-être ajouter un exemple de scénario pour expliquer la différence?
Pierre.Vriens
@ Pierre.Vriens Est-ce mieux?
Dan Cornilescu

Réponses:

6

Pour autant que je sache, vous recherchez un outil qui rejettera les validations qui interrompent la construction - un outil CI ne sera probablement pas en mesure d'empêcher les régressions en corrigeant réellement votre code, mais il peut vous empêcher d'ajouter du mauvais code au référentiel.

Atlassian a quelques applications intéressantes des crochets Git :

Les hooks de pré-réception côté serveur sont un complément particulièrement puissant à l'intégration continue car ils peuvent empêcher les développeurs de pousser le code vers le maître, à moins que le code ne remplisse certaines conditions - comme les gardiens ninja d'élite, le protégeant des mauvais codes.

Si vous utilisez Git, les hooks sont très puissants (et il existe des hooks similaires pour SVN , Mercurial et d'autres systèmes de contrôle de version), et vous pourriez trouver utile de les utiliser pour exécuter des vérifications de pré-validation.

La documentation Git a une page sur la création d'un hook pour rejeter les pushs s'ils ne répondent pas à certains critères qui pourraient facilement être adaptés à ce cas d'utilisation.

Cependant, beaucoup de gens diraient que rejeter les validations est une mauvaise idée sur une featurebranche - vous perdrez simplement du temps à lutter contre votre système CI lorsque la construction s'arrête pour une raison quelconque, au lieu de corriger le bogue.

Sur la masterbranche, il peut être judicieux de rejeter les fusions interrompues, car vous voudrez peut-être vous assurer qu'il se construit toujours. Pour une featurebranche, vous allez briser inévitablement les choses, et que le code ne va pas en production maintenant , il est plus logique juste pour vous avertir que de rejeter réellement votre commettras tout à fait.

Aurora0001
la source
Eh bien, à quoi sert une image sw qui se construit, mais le DOA est-il un test prospectif? Les développeurs ne peuvent pas tester leurs modifications de code même s'ils construisent, ils seraient donc tout aussi bloqués. Donc, en général, j'étendrais le rejet de la validation à tout ce qui échoue à un contrôle QA minimum, choisi en équilibrant 2 exigences contradictoires: aussi élevé que possible pour maximiser le nombre de développeurs protégés contre le blocage et aussi bas que possible de sorte que la vérification de la QA retarde don 'ralentissez pas trop le processus.
Dan Cornilescu
Un exemple de cela pourrait être le modèle de demande d'extraction dans lequel vous pouvez imposer certaines restrictions quant à la fusion ou non d'une demande d'extraction. Par exemple, nous (mon entreprise) utilisons Atlassian Bitbucket Server et il existe des options pour exiger au moins N nombre d'approbations et X nombre de builds en cours pour la branche donnée avant qu'une fusion ne soit autorisée à fusionner une demande de tirage. Cela ne le rejette pas carrément. Mais empêche la fusion accidentelle lorsque les tests échouent ou que d'autres yeux n'ont pas encore vu le code.
Andy Shinn
@AndyShinn: Oui, je trouve cela très utile - GitHub propose également des branches protégées et des vérifications sur les demandes d'extraction , qui sont souvent utiles.
Aurora0001
1
Un argument pour autoriser le code cassé dans les branches de fonctionnalités est qu'il permet aux développeurs de pousser le code sur lequel ils travaillent vers le référentiel, même s'il n'est pas encore tout à fait prêt. Cela peut être utile pour partager du code avec d'autres personnes pour les premières révisions de code / architecture avant que les choses ne soient prêtes, pour aider à résoudre les problèmes de débogage, ou pour quelqu'un qui part en vacances pour mettre un travail partiellement effectué là où d'autres peuvent y accéder. Pour les branches de fonctionnalités, je ne mettrais que des éléments comme des linters et des crochets de pré-validation.
bradym
2

Aucun outil ne pourrait garantir aucune régression - cela dépend beaucoup plus de vos tests que de l'outil qui les exécute. Cependant, vous pouvez aider à empêcher les régressions qui seront interceptées d'entrer dans la branche d'intégration. Vous pouvez le faire avec des hooks de pré-validation, mais c'est souvent plus facile avec les demandes de tirage (que vous utilisez déjà, espérons-le, pour l'examen du code par les pairs).

Si une branche est à jour avec son amont (où le PR fusionne) et que ses tests réussissent, ils passeront quand même après la fusion; l'état de la branche cible après la fusion correspondra à l'état de la branche source avant la fusion.

Il n'est généralement pas particulièrement difficile (selon les outils utilisés) d'indiquer à la fois si la branche source dans un PR est à jour avec la cible et si elle a une construction de CI réussie. Vous pouvez l'utiliser comme exigence (par stratégie et / ou mise en œuvre dans le logiciel) pour fusionner la demande d'extraction.

Adrian
la source
"Si une branche est à jour avec son amont (où le PR fusionne) et que ses tests réussissent, ils passeront quand même après la fusion" - Pourquoi? Une fusion est une discontinuité, elle apporte des inconnues. Comme les conflits - le code peut même ne pas se construire avant d'être résolu. Vous devez exécuter les tests et confirmer qu'ils réussissent pour toute fusion de branche. Je dirais même pour une avance rapide, si vous voulez jouer en toute sécurité. Voir apartsw.com/insights/2016/11/16/…
Dan Cornilescu
Oui, une telle garantie est possible, vérifiez ma réponse. Eh bien, je devrais peut-être clarifier: par régression, je veux dire des résultats pires que ceux de la ligne de base de la branche (et en ignorant la possibilité de faux positifs, ceux-ci doivent être traités car ils peuvent fausser la ligne de base, faire dérailler le tout et nécessiter une intervention humaine). Les faux négatifs intermittents ne sont qu'une nuisance, ralentissent les choses, mais peuvent être traités.
Dan Cornilescu
Vous ne pouvez garantir aucune régression, vous ne pouvez garantir aucune régression détectée. Si un changement provoque une régression non détectée par un test, c'est une régression qu'un outil CI ne peut garantir. Et bien que la fusion de deux ensembles de modifications apporte des inconnues, vous pouvez choisir de le faire dans la branche de fonctionnalité (en fusionnant l'amont) avant de fusionner dans l'autre sens. Si la source est à jour avec la cible, il s'agit d'une simple fusion (avance rapide), et ensuite l'état cible sera identique à l'état source avant la fusion, donc si les tests ont réussi avant, ils passeront après.
Adrian
Fractionnement des poils. L'outil CI peut être configuré avec un test pour détecter et ainsi protéger contre la régression qui vous intéresse. Je ne discuterai pas trop des fusions - mon objectif est de les éviter autant que possible, elles sont juste des problèmes dans l'ensemble :)
Dan Cornilescu
Mon point est que ce n'est pas l'outil CI offrant cette protection, c'est vous, en écrivant les tests. L'outil CI ne peut fournir aucune garantie au-delà des tests que vous fournissez.
Adrian
1

De véritables outils d'intégration continue (par opposition à de simples tests continus) comme Reitveld et Zuul peuvent vous aider, bien qu'ils ne soient aussi bons que les tests que vous écrivez et les revues de code que vous faites.

coderanger
la source
Mais Reitveld semble être un outil de révision de code collaboratif, pas un outil CI, est-ce que je manque quelque chose? Voici ce que j'ai regardé: github.com/rietveld-codereview/rietveld
Dan Cornilescu
Zuul semble en effet être lié, je vais l'étudier de plus près.
Dan Cornilescu
Il ne fait pas de test, mais il gère certains aspects de la gestion des succursales, agissant comme un système de contrôle d'accès, ce qui est le meilleur pari pour empêcher le mauvais code d'entrer en bloquant la fusion.
coderanger
Je vois ce que tu veux dire. Eh bien, cela peut aider à la qualité globale du code, mais en soi, n'apporte aucune garantie. Deux changements parfaitement bons qui réussissent toutes les vérifications d'AQ indépendamment peuvent toujours provoquer des ruptures lorsqu'ils se rencontrent dans la branche.
Dan Cornilescu
1

Utilisez GitLAB, vous pouvez définir des paramètres de projet pour n'autoriser une fusion que lorsque le pipeline réussit, donc peut avoir une intégration vraiment continue, combinez cela avec l'ajout de votre assurance qualité à la liste des approbations de fusion et avec des environnements dynamiques, vous pouvez avoir une assurance qualité avant de fusionner avec le maître.

Danny Goossen
la source
Cela fonctionne, mais uniquement si vous n'autorisez pas une 2e fusion à démarrer les contrôles d'assurance qualité avant la fin de la fusion précédente, sinon la 2e fusion ne verra pas la 1ère, laissant de la place aux régressions. En d'autres termes, les fusions (y compris leurs contrôles d'assurance qualité) doivent être complètement sérialisées, ce qui n'est pas adapté aux grandes équipes.
Dan Cornilescu
0

ApartCI est un système CI conçu précisément pour empêcher les régressions, garantissant ainsi un niveau de qualité de branche plat ou croissant. Toujours en version bêta.

Il orchestre les vérifications de pré-validation centralisées de manière à garantir qu'une modification n'est validée qu'après avoir été vérifiée, ainsi que toutes les autres modifications validées avant elle, pour atteindre ou dépasser le dernier niveau de qualité de branche.

C'est la principale différence par rapport aux vérifications de pré-validation traditionnelles effectuées par les développeurs, souvent effectuées en parallèle, ce qui laisse la place aux régressions causées par des changements interférents qui n'ont jamais été testés ensemble.

L'outil est également conçu pour évoluer facilement - capable de maintenir des taux très élevés de changements de candidats entrants et de prendre en charge des centaines de milliers de développeurs travaillant dans la même branche d'intégration.

Avertissement: je suis l'auteur de l'outil et fondateur de la société qui le propose. Toutes mes excuses pour l'annonce.

Dan Cornilescu
la source
C'est bien que vous ayez ajouté l'avertissement, mais personnellement, je pense à poser une question et à y répondre en faisant la promotion de votre propre entreprise ou de vos produits comme une forme de spam.
THelper
J'ai posé une question sur la méta si cela est autorisé ou non: meta.devops.stackexchange.com/q/59
THelper
SnapCI l'a fait aussi. DÉCHIRURE.
paul_h
@paul_h, sauf si je manque quelque chose SnapCI et son GoCD de remplacement recommandé sont tous deux basés sur des vérifications post-validation (déclenchées par l'interrogation du SCM), ils sont donc toujours en surveillance uniquement. Sauf peut-être pour les contrôles PR, mais à moins que ces contrôles ne soient complètement sérialisés, ils ne peuvent que réduire les taux d'occurrence de régression, mais pas les éliminer complètement.
Dan Cornilescu
Dan, ne votant pas, accroche. Et à une branche de relations publiques de courte durée qui n'est pas encore fusionnée en trunk / master - trunkbaseddevelopment.com/game-changers/…
paul_h