Quand faut-il réviser le code en intégration continue?

Nous essayons de passer à un environnement d'intégration continue, mais nous ne savons pas quand procéder à la révision du code. D'après ce que j'ai lu sur l'intégration continue, nous devrions essayer de vérifier le code aussi souvent que plusieurs fois par jour. Je suppose que cela signifie même pour les fonctionnalités qui ne sont pas encore complètes.

La question est donc de savoir quand faire les révisions de code.

Nous ne pouvons pas le faire avant d’avoir archivé le code, car cela ralentirait le processus car nous ne serions pas en mesure d’effectuer des archivages quotidiens, sans parler de plusieurs archivages par jour.

En outre, si le code que nous archivons compile simplement mais ne comporte pas une fonctionnalité complète, procéder à une révision du code est alors inutile, dans la mesure où la plupart des révisions de code sont effectuées au fur et à mesure que la fonctionnalité est finalisée. Cela signifie-t-il que nous devrions procéder à des révisions de code lorsqu'une fonctionnalité est terminée, mais que le code non révisé sera inséré dans le référentiel?

OMI, vous devez vérifier le code avant qu’il ne soit publié sur le réseau principal afin que ce dernier n’ait que le code de la plus haute qualité.

OTOH, on pourrait dire que «pourquoi se donner la peine de passer en revue si l'automatisation du test de CI n'a pas fonctionné?», Le mieux serait peut-être de donner à chaque développeur une branche privée que le serveur de CI va créer et tester. . De cette façon, ils s’engagent et poussent là-bas, puis, une fois l’opération passée, faites-le passer en revue, puis fusionnez-le avec Mainline (où il sera exécuté à nouveau via le serveur CI).

Vous devez absolument consulter le code non complet des fonctionnalités pour vous assurer que l'échafaudage des futures fonctionnalités est en place, ou du moins que rien n'est mis en place qui empêcherait la mise en œuvre desdites fonctionnalités futures.

Notez également que les révisions de code ne doivent pas nécessairement être lentes, ni synchrones: un outil tel que gerrit ou reviewboard, par exemple, peut les rendre asynchrones et relativement simples.

(Divulgation complète: je travaillais auparavant pour SmartBear, concepteur de Code Collaborator, un outil de révision de code)

Configurer la programmation en binôme?

Tout le code est révisé au fur et à mesure de la frappe, sans prolonger le processus ni introduire une autre étape.

Voici l'extrait de l'auteur de la livraison continue:

Jez Humble écrit comme:

Je suis en train d'écrire un article sur ce sujet. La réponse courte est la suivante:

• La meilleure façon de réviser le code est de programmer par paires
• C'est une mauvaise idée de fusionner la fusion avec Mainline - en créant une branche distincte, par exemple - dans le cadre d'un processus de révision formel. Cela empêche l’intégration continue (le meilleur moyen de réduire le risque de mauvais changements, ce que vous voulez vraiment réaliser).
• Je pense que Gerrit est un bon outil, mais il devrait être utilisé après l' enregistrement (c'est ainsi qu'il a été conçu). Une partie du travail des développeurs principaux consiste à examiner toutes les check-ins. Ils pourraient, par exemple, s'abonner à un flux.

Pour résumer: la révision du code est bonne. Tellement bien, nous devrions le faire de manière continue, à travers la programmation par paires et la révision des commits. Si un développeur senior trouve un mauvais commit, il devrait faire équipe avec la personne qui l'a commis pour les aider à résoudre le problème.

Il est mauvais de fusionner la fusion avec une ligne principale lors d'une révision formelle, et créer des branches est très mauvais, pour la même raison que les branches de fonctionnalité sont mauvaises.

Merci,

Jez.

Le lien d'origine est: https://groups.google.com/forum/#!msg/continuousdelivery/LIJ1nva9Oas/y3sAaMtibGAJ

Je ne sais pas si c'est la meilleure façon de le faire ... mais je vais expliquer comment nous le faisons. Un ou plusieurs développeurs travaillent sur une branche donnée et engagent leur code aussi souvent qu'ils le peuvent afin d'éviter de perdre du temps en fusion, ce qui n'aurait pas été le cas autrement. Ce n'est que lorsque le code est prêt qu'il est commis dans la tête. Maintenant, c'est pour les commits et le truc de branche / tête.

En ce qui concerne la révision du code, nous utilisons Sonar comme outil d’intégration continue (et Maven / Jenkins pour interagir avec Sonar) afin de nous fournir de nouveaux résultats de test, une couverture du code et une révision automatique du code tous les matins Les développeurs peuvent consacrer au maximum une heure chaque matin à résoudre leurs problèmes / odeurs de code. Chaque développeur assume la responsabilité (en étant fier aussi!) De la fonctionnalité qu'il écrit. Il s’agit maintenant de la révision automatique de code, ce qui est formidable pour détecter les problèmes techniques / architecturaux potentiels, mais le plus important est de vérifier si ces nouvelles fonctionnalités implémentées répondent bien aux attentes de l’entreprise.

Et pour cela, il y a deux choses: les tests d'intégration et la révision de code par les pairs. Les tests d'intégration aident à être raisonnablement convaincus que le nouveau code ne rompt pas le code existant. En ce qui concerne l'examen du code par les pairs, nous le faisons le vendredi après-midi, ce qui est un peu plus décontracté :-) Chaque développeur est affecté à une branche sur laquelle il ne travaille pas, il faut un certain temps pour lire les exigences de la nouvelle fonctionnalité en premier, puis vérifie ce qui a été fait. Son travail le plus important est de s'assurer que le nouveau code fonctionne comme prévu compte tenu des exigences, qu'il n'enfreint pas nos propres "règles" (utilisez cet objet pour cela, et non celui-là), qu'il est facile à lire et qu'il permet extension facile.

Nous avons donc deux critiques de code, une automatique et une "humaine", et nous essayons d'éviter de commettre du code non revu dans la branche HEAD. Maintenant ... Cela arrive parfois pour diverses raisons, nous sommes loin d'être parfaits, mais nous essayons de maintenir un juste équilibre entre qualité et coût (temps!)

@pjz fournit également une bonne réponse et mentionne les outils de révision de code. Je n'en ai jamais utilisé, donc je ne peux rien dire à ce sujet ... bien que j'ai déjà été tenté de travailler avec Crucible, car nous utilisons déjà JIRA .

Je pense que le concept principal qui aidera est celui d’une zone de "mise en scène".

Oui, vous ne voulez pas vérifier le code qui est cassé. Mais vous devriez également vérifier le code fréquemment. Cela implique-t-il la perfection? ;) Non. Utilisez simplement plusieurs zones et un DVCS comme git.
De cette façon, vous apportez des modifications (localement) et vous les validez fréquemment au fur et à mesure que vous testez et développez jusqu'à ce que les tests réussissent. Ensuite, vous appuyez sur une zone intermédiaire pour la révision du code.

Vous devriez alors pousser de Staging à d'autres efforts d'assurance qualité tels que les tests de navigateur et les tests d'utilisateur. Enfin, vous pouvez accéder à une zone d’essai en volume, puis à la production.

Il y a également des flux de travail dans ce domaine, par exemple, chaque personne travaillant dans la branche principale ou utilisant des branches individuelles pour tous les efforts.

L'intégration continue elle-même peut également se produire à plusieurs niveaux. Cela peut être local sur une machine de développement 'jusqu'à ce que les tests soient réussis' et cela peut aussi être dans les zones de transfert et de mise en attente pour le moment où le code leur est envoyé.

Découpez la révision du code et l'intégration continue!

Pourquoi les as-tu combinées?

Nous utilisons git flow pour nos référentiels et nous procédons à la révision de nos codes lorsqu'il s'agit de fusionner dans la branche develop.

Tout ce qui est en développement est complet, déployable et révisé.

Nous avons également mis en place des CI pour nos branches en développement et principales.

Je pense vraiment, vraiment, vraiment que vous auriez besoin d'un DVCS (par exemple, mercurial, git) pour le faire naturellement. Avec un CVCS, vous auriez besoin d'une branche et espérez que votre dieu soit égal à l'enfer.

Si vous utilisez un DVCS, vous pouvez hiérarchiser le processus d'intégration afin que le code le revoie déjà avant qu'il n'arrive sur le serveur CI. Si vous ne possédez pas de DVCS, le code arrivera sur votre serveur CI avant d'être révisé, à moins que les réviseurs de code ne l'examinent sur la machine de chaque développeur avant de soumettre leurs modifications.

Une première façon de le faire, spécialement si vous n’avez pas de logiciel de gestion de référentiel capable de publier des référentiels personnels (par exemple, bitbucket, github, rhodecode), consiste à avoir des rôles d’intégration hiérarchique. Dans les schémas suivants, vous pouvez faire en sorte que les lieutenants examinent le travail des développeurs et que le dictateur, en tant qu’intégrateur principal, examine la façon dont les lieutenants ont fusionné le travail.

Si vous disposez d'un logiciel de gestion de référentiel, vous pouvez également utiliser un flux de travail tel que celui-ci:

Les logiciels de gestion de référentiels permettent généralement d’émettre des notifications en cas d’activité dans les référentiels (par exemple, courrier électronique, flux RSS) et d’autoriser les demandes de retrait . La révision du code peut se produire de manière organique lors des demandes d'extraction, car ces dernières amènent généralement les gens à engager des conversations pour intégrer le code. Prenez cette demande publique comme exemple. Le gestionnaire d’intégration ne peut en réalité pas permettre au code d’arriver dans le référentiel béni (aussi appelé «référentiel central») si le code doit être corrigé.

Plus important encore, avec un DVCS, vous pouvez toujours prendre en charge un flux de travail centralisé. Vous n'avez pas besoin d'un autre flux de travail très sophistiqué si vous ne le souhaitez pas. Mais avec un DVCS, vous pouvez séparer un référentiel de développement central du CI. serveur et donnez à quelqu'un l’autorisation de transférer les modifications du référentiel dev vers le référentiel CI une fois la session de révision du code terminée .

PS: le crédit pour les images va à git-scm.com

Pourquoi ne pas avoir plus d'un référentiel? Un pour le travail "quotidien", pilotant un serveur d'intégration continue, exécutant tous les tests unitaires et les tests d'intégration pour obtenir la boucle de rétroaction étroite et agréable, et un autre pour le travail "stable", où les commits sont moins fréquents, mais doivent passer en revue.

En fonction du chemin emprunté par les modifications au fur et à mesure qu'elles se déplacent dans le système, cela peut s'avérer être une solution un peu complexe et fonctionnerait mieux si vous utilisiez des outils tels que Git ou Mercurial Queues, mais beaucoup d'organisations font quelque chose de similaire.

Cela signifie-t-il que nous devrions procéder à des révisions de code lorsqu'une fonctionnalité est terminée, mais que le code non révisé sera enregistré dans le référentiel?

Bien au-dessus est la façon dont j'ai vu le faire dans au moins trois projets qui utilisaient intensivement l'intégration continue et, d'après mes souvenirs, cela a fonctionné à merveille. Cette pratique est connue sous le nom de révision de code post-commit. Recherchez ce terme sur le Web si vous êtes intéressé par les détails.

• ^{D'autre part, le seul cas où j'ai été impliqué dans un projet essayant de "marier" des révisions de code pré-commit avec CI était plutôt pénible. Bien, lorsque tout s'est déroulé sans heurts, tout s'est bien passé, mais des interruptions même peu fréquentes (comme lorsque les réviseurs principal et de secours étaient indisponibles pendant quelques heures, par exemple) ont créé un stress notable. J'ai aussi remarqué que le moral de l'équipe avait quelque peu souffert - il y avait un peu trop de conflits.}

Premièrement, nous devrions clarifier le concept "d'intégration continue". Dans les méthodes de développement traditionnelles, l'intégration continue signifie que nous pouvons intégrer et construire quotidiennement notre référentiel de code source, ce qui évitera les pièges de "l'enfer de l'intégration". Les révisions de code se font toujours entre la période de codage et les tests unitaires. Nous devons garantir que le code fusionné avec la branche peut être compilé sans erreur. Il arrive rarement que des parties de la fonctionnalité fusionnent avec la branche, car il est difficile de gérer la cohérence de l'interface et de compiler des erreurs.

L'intégration continue est populaire dans le processus de programmation extrême. Le développement piloté par les tests ajoute la programmation par paire, qui fait partie intégrante d'un processus de révision de code, ce qui facilite l'intégration continue. Extreme Programming est en soi un processus continu d’examen et d’intégration de code. Les revues de code existent partout.

Dans certaines communautés open source, les révisions de code sont exécutées juste avant la fusion du code avec la branche. Les personnes les plus expérimentées de cette équipe sont toujours chargées de réviser le code et de décider si le code peut être fusionné avec la branche principale. De cette façon, la période d'intégration continue est un peu plus longue mais la qualité du code est un peu meilleure.

Revenez à la question. Il n'y a pas de réponse standard pour savoir quand procéder à la révision du code, cela dépend de votre processus de développement d'origine et de la mise en œuvre réelle de votre intégration continue.