Le développeur doit-il attendre la fin du pipeline CI ou démarrer la tâche suivante après avoir poussé

8

Mon entreprise intègre CI / CD, jusqu'à présent, nous avons mis en œuvre CI à partir de ce que je comprends. Actuellement, lorsqu'un développeur envoie du code à notre dépôt git, le pipeline CI s'exécute.

Actuellement, notre pipeline de CI comprend la construction du projet et l'analyse de code statique pour s'assurer qu'il répond à nos normes de codage. Nous mettrons en œuvre des tests ensuite. La compilation et l'analyse de code statique prennent actuellement environ 3 minutes. D'après ce que j'ai lu, résoudre les problèmes tout de suite est essentiel pour CI / CD. Je pense que lorsque nous ajouterons des tests unitaires, le pipeline pourrait prendre environ 10 minutes pour fonctionner.

Donc, ma question est quand un développeur fait une demande de pull / merge doit-il attendre la fin du pipeline CI ou simplement passer à la tâche suivante et revenir pour résoudre les problèmes de pipeline s'ils existent? Ou devraient-ils s'asseoir et regarder le pipeline fonctionner?

continuous-integration git continuous-delivery

— iqueqiorio
source

7

Asseyez-vous et regardez le pipeline fonctionner?

Non, ce n'est pas ainsi que vous travaillez efficacement.

Les développeurs poussent leurs validations vers le référentiel de contrôle de code source, puis le pipeline CI / CD est déclenché.

Les développeurs peuvent publier une demande d'extraction bien écrite à tout moment. Il y a généralement une marque visuelle représentant une "construction en cours" / "une construction ayant échoué" / "une construction réussie".

En règle générale, une brach peut être fusionnée lorsque tous ces critères sont remplis:

au moins un approbateur / ou autant qui doit approuver a approuvé.
une "construction réussie"
aucun conflit de fusion non résolu

Si l'un de ces critères n'est pas rempli, ils doivent être corrigés, mais le développeur le fait chaque fois qu'il a le temps ou la priorité pour effectuer cette tâche.

— Jonas
source

2

Bonne réponse. Beaucoup de gens ne savent pas qu'avec GitHub SaaS, vous pouvez demander à circle-ci ou à un autre CI de créer les modifications proposées dans une demande d'extraction avant que la modification ne soit fusionnée. J'ai donc vu GitHub Enterprise sur site utilisé sans que cette fonctionnalité soit utilisée: la ferme Jenkins sur site ne s'exécute qu'une fois que vous avez fusionné le PR, ce qui peut être interrompu à moins que le développeur n'ait effectué une fusion et une construction complètes. Cela rend alors la vie beaucoup plus complexe. Il y a des années, teamcity vous permettait de faire un build ci sur une ferme avant même de vous engager à éviter de casser une branche. La construction uniquement après la publication du problème est une méthode de travail héritée.

— simbo1905

@ simbo1905 tout va bien, sauf que la vérification PR n'est efficace à 100% que si elle est entièrement sérialisée. Le chevauchement des PR signifie que les changements respectifs ne se prennent pas en compte et peuvent toujours interférer les uns avec les autres, provoquant une rupture lorsqu'ils atterrissent dans la branche d'intégration. Même s'ils n'ont pas de conflits de fusion ou ne touchent pas aux mêmes fichiers, des conflits fonctionnels sont toujours possibles.

— Dan Cornilescu

@DanCornilescu Les RP agréés peuvent passer des versions indépendantes mais entrer en conflit. On renomme une méthode, on ajoute du code qui utilise l'ancien nom de méthode. Les deux RP passent des builds en parallèle. Une fois approuvé et fusionné, le code ne sera pas compilé. Les grands projets utilisent un bot de fusion comme bors-ng. L'évaluateur ne le fusionne pas, il dit au bot d'essayer. Le bot ne fait des fusions en série qu'après une nouvelle version où il avait combiné ce qui se trouve dans sa file d'attente de fusion. Dans notre exemple, il essaiera une version fusionnée des PR combinés. Il échoue alors essayez uniquement le premier ajouté à sa file d'attente, réussissez, fusionnez, puis créez et rejetez l'autre.

— simbo1905

1

Je recommande de faire de votre mieux pour vous assurer que le pipeline dure moins de 10 minutes. Vous pouvez exécuter vos tests en parallèle pour l'activer. Comme jonas a répondu, ils peuvent ensuite passer du temps à créer une demande d'extraction (pendant que le pipeline est en cours d'exécution).

Le changement de contexte est mauvais pour la productivité, plutôt que de reprendre une autre tâche, je recommande au développeur d'utiliser ce temps pour travailler sur tout ce qui concerne le changement qu'il vient d'apporter. Peut-être y a-t-il une documentation qui pourrait être mise à jour à ce sujet. Si c'est une fonctionnalité remarquable, il pourrait créer un court gif montrant comment travailler avec. Même en regardant à nouveau leur changement de code peut les aider à réfléchir à la façon dont ils pourraient l'améliorer la prochaine fois. Ce temps pourrait également être utilisé pour examiner les autres demandes d'extraction des développeurs et les modifications de code.

S'ils passent à développer une autre fonctionnalité au cours de ces 10 minutes, il faudra probablement plus de 10 minutes avant d'y revenir et le travail sera moins frais dans leur esprit. Si le CI échoue alors, il leur sera plus difficile de se rappeler ce qui aurait pu mal tourner et de corriger le code.

— Samuel Garratt
source

C'est tellement vrai: CI à mon avis ne devrait jamais fonctionner plus longtemps que sur la machine du développeur.

— Peter Muryshkin

0

Ok, supposons donc que vous disposez d'un outil de contrôle de version comme Git et CI Jenkins. Donc, Dev crée une branche de fonctionnalité pour un problème. Vous avez un pipeline multibranches ou un flux de travail dans votre outil CI qui détecte cette branche de fonctionnalité lors de la prochaine analyse et exécute les étapes CI.

Donc, les choses qui doivent être assurées sont:

Avant d'augmenter le PR / MR, le travail CI est vert. S'il n'est pas vert, PR / MR ne doit pas être augmenté. De toute évidence, le développeur peut effectuer d'autres tâches, puis revenir et résoudre le problème de cette tâche, c'est son choix en fonction de la priorité de la tâche. Vous pouvez même contrôler l'augmentation de tout PR en vérifiant ses paramètres CI. (Si vous ne faites pas tellement confiance à votre développeur et qu'il soulève continuellement des PR pour les builds cassés)
Une fois le PR levé, un réviseur de code passera en revue et fusionnera si tout est OK. Le réviseur de code peut être n'importe quel autre développeur. Sa responsabilité est de revoir le code, voir s'il est dans les critères de "Définition de Terminé". DoD est principalement un terme agile, mais agile et DevOps vont de pair.
Une fois le code fusionné, le CI de la branche principale doit être vert. Sinon, le code doit être annulé et le problème doit être résolu car, généralement, la branche principale est également déployée dans les environnements et ne pas revenir en arrière signifie que l'environnement entier sera rompu.

De toute évidence, les actions après la construction informeront le committer que Hey, vous avez cassé la construction, afin que les développeurs puissent effectuer leurs autres tâches, ils recevront des e-mails de toute façon.

— deosha
source