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

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.

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.

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.

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.

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.

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.