comment rester efficace quand un build est presque toujours cassé


25

Je travaille dans une équipe de taille moyenne qui partage le même code source et tout en ayant une intégration continue en place, mais comme nous devons tous travailler dans la même branche, la construction est presque toujours interrompue.

Comme nous avons également une règle, qui a été introduite récemment pour atténuer les builds cassés, qui stipule que personne n'est autorisé à s'enregistrer pendant la construction est rouge.

Cela dit, pendant une journée, tout le monde a une poignée de fenêtres de 10 à 15 minutes où nous avons pu nous enregistrer.

Et au fur et à mesure que l'équipe s'agrandit, les fenêtres des opportunités d'enregistrement se réduisent encore plus. Cela oblige les développeurs à accumuler leurs modifications localement, ce qui se traduit par des ensembles de modifications plus importants, ce qui rend encore plus difficile de garantir que les modifications ne cassent rien. Vous pouvez voir le cercle vicieux.

Que pouvez-vous recommander pour me permettre de continuer à travailler efficacement dans un environnement comme celui-ci. Aussi, veuillez garder à l'esprit que je suis un développeur, pas un gestionnaire, et que je ne peux pas beaucoup changer le processus ou le comportement d'autres personnes.


8
Pourquoi ne pouvez-vous pas avoir de succursales?
Zavior

6
la solution apparente serait de mettre en place votre branche "personnelle" et de vous y engager, puis d'intégrer cette branche avec celle avec laquelle l'équipe travaille
gnat

@Zavior ayant une branche implique une complexité supplémentaire et donc un travail supplémentaire - fusion d'une branche en tronc. Et cela augmente également la complexité - non seulement je devrais garder le tronc à jour, mais je devrais également faire de même pour ma branche.

6
@Andrew accumuler des changements sur la machine locale est la première chose à faire, quoi qu'il arrive. Les autres problèmes que vous mentionnez sont également réels, mais celui-ci est le premier à résoudre
gnat

6
Je ne comprends pas vraiment comment ils peuvent pousser les changements s'ils n'ont pas été mis à jour localement, et pourquoi ils poussent les builds cassés du tout tbh
Inutile

Réponses:


54

Pour commencer, ce commentaire:

... avoir une branche implique une complexité supplémentaire et donc un travail supplémentaire ...

est totalement faux. Je l'entends souvent de gens qui ne sont pas habitués à la ramification, mais c'est toujours faux.

Si de nombreux développeurs accumulent des modifications localement, leurs modifications locales constituent une branche de facto du référentiel principal.

Quand ils poussent enfin, c'est une fusion de facto .

Le fait que vos branches et vos fusions soient implicites ne supprime pas la complexité supplémentaire qui vous préoccupe, il la cache simplement. La vérité est que rendre ce processus explicite pourrait vous aider (pluriel = toute l'équipe) à apprendre à le gérer.


Maintenant tu dis

personne n'est autorisé à s'enregistrer alors que la construction est rouge

mais dans ce cas, la construction ne peut jamais être corrigée, elle ne peut donc pas être tout à fait précise.

En général, s'il est raisonnable de construire localement (c'est-à-dire que la construction n'est ni trop grande ni trop lente), les développeurs devraient le faire avant de pousser quand même.

Je suppose que ce n'est pas le cas, car ils ne pousseraient pas les builds cassés en premier lieu, mais ce serait génial si vous pouviez clarifier ce point.

En général, la réponse à

comment rester efficace quand un build est presque toujours cassé

est: arrêtez de casser la construction .


23
+9000 pour "Arrêtez de casser la version." Sérieusement. L'intégralité, le point entier de l'intégration continue est d'arrêter de casser la construction et, si elle est cassée, de la réparer aussi vite et aussi près de la rupture que possible.
Patrick Hughes

@Inutile, j'aime votre réponse générale, mais je pense que j'aurais dû corriger ma question. Personnellement, je ne casse pas la construction, et en même temps, je ne veux pas faire de vagues qui poussent beaucoup les autres afin qu'ils puissent arrêter de casser la construction. J'aime savoir - y a-t-il quelque chose que je pourrais faire moi-même, pour rester plus productif moi-même, dans un environnement où la construction est souvent cassée, et je ne m'attends pas à ce que cet état cassé du soit changé de sitôt. Souhaitez votre avis à ce sujet. À votre santé.

6
Eh bien, vous pouvez travailler sur votre propre branche et être sélectif sur les changements en amont que vous fusionnez sur cette branche (c'est-à-dire que vous ne pouvez fusionner que lorsque la version est verte). Mais cela réduit vraiment l'interaction avec le reste de l'équipe, alors qu'il serait préférable dans l'ensemble de réparer l'équipe afin que vous puissiez interagir en toute sécurité.
Inutile du

14

les développeurs ... accumulent leurs modifications localement ... Vous pouvez voir le cercle vicieux.

C'est vraiment vicieux. Accumuler les changements localement est un gros drapeau rouge indiquant que quelque chose est gravement pourri dans le processus de développement. Cela détruit en quelque sorte le but d'avoir un système de contrôle de version .

Tant que vous voulez éviter de modifier le processus ou le comportement d'autres personnes, la solution la plus naturelle serait de configurer votre propre branche et de l'utiliser pour "accumuler" vos modifications (pour être davantage intégré à la branche d'équipe lorsque vous obtenez un chance).

En fait, s'il y a plus de gars comme vous, vous pouvez même collaborer et établir une branche de développement partagée pour échanger librement vos mises à jour sans être gêné par des idées de gestion incompétentes. La ramification permet de nombreuses façons différentes de simplifier le travail d'équipe.

  • Remarque: chaque fois que le gestionnaire fait ou dit quelque chose qui vous oblige à éviter les commits, à conserver le code localement, à traduire ses mots en gras et en clair "je suis incompétent" .

s'il vous plaît gardez à l'esprit que je suis un développeur, pas un gestionnaire, et que je ne peux pas beaucoup changer le processus ou le comportement d'autres personnes ...

Par souci de précision, vous pouvez réellement , ce sont des questions d'influence et de communication et il n'est pas vraiment nécessaire d'être en position de pouvoir pour changer les choses à leur goût (recherchez sur le Web quelque chose comme "gérer" si vous suis intéressé par plus de détails).

Cependant, c'est plutôt lourd et fastidieux et je peux parfaitement comprendre si l'on préfère simplement rester concentré sur le codage, avec peu d'implication dans la politique - donc si vous ne voulez pas (même si en théorie vous le pouvez ), c'est compréhensible. :)


7

Je suis sensible à l'idée que vous vous sentez impuissant à changer l'environnement, mais je pense que cette situation constitue un sérieux défi pour votre professionnalisme en tant que programmeur.

Que se passerait-il si un chirurgien stockait des scalpels sales avec des scalpels propres? Que se passerait-il si un plombier ne testait pas les tuyaux qu'il avait installés? Que se passerait-il si un violoniste jouait toujours en désaccord avec l'orchestre?

Pourquoi les programmeurs devraient-ils être exemptés du travail d'équipe et de la courtoisie commune? En tant que membre de cette équipe, vous partagez la responsabilité du résultat. Il est irresponsable d'ignorer l'équipe car elle sabote ses propres efforts.

Je suis curieux d'où vient la règle selon laquelle "personne n'est autorisé à s'enregistrer alors que la construction est rouge"? C'est une bonne règle si cela concentre ensuite tout le monde sur la correction de la construction. J'essaierais de montrer l'exemple et d'aider à réparer la construction chaque fois qu'elle est cassée. Avouons-le, vous ne faites rien d'autre de toute façon. Si cela vous ennuie, je vous suggère d'exprimer ces préoccupations. La voix de quelqu'un qui essaie activement d'améliorer une situation a plus d'influence que le gars qui grogne dans le coin.


5

Je pense que tant que vous pensez que vous êtes "juste un développeur" et donc vous ne pouvez pas changer les choses, vous allez souffrir de ce problème.

Ce que vous devez faire, c'est que vous devez annuler chaque validation du référentiel à chaque fois que quelqu'un rompt la génération, puis dire à ce type qu'il vient de rompre la génération et que cela doit s'arrêter. Vous devez également expliquer cette situation au manager et lui dire que la productivité de votre équipe souffre à cause de ce problème.

Vous devez faire tout ce que vous pouvez pour changer le processus et dire plutôt que vous êtes désolé plus tard au lieu de demander la permission.

Je pense que vous et votre équipe êtes dans une situation où le processus doit être changé et vous ne pouvez pas travailler efficacement avec ce modèle cassé. Je pense aussi qu'il est de votre responsabilité de faire quelque chose contre ce problème lorsque vous l'avez reconnu. Si personne d'autre ne veut rien faire contre le problème, c'est vous qui devez!


-2 et personne ne veut partager pourquoi .. heh heh.
hequ

1
Vous ne pouvez pas faire une omelette sans casser des œufs.
William Payne

2

Je peux comprendre votre sort, j'ai fait face à une situation similaire avec mon dernier projet au travail. Nous avons fini par implémenter une sorte de système de "patate chaude" où le développeur qui a récemment cassé la version devait la garder / nounou / la surveiller jusqu'à ce qu'elle soit corrigée ET réussir tous nos tests de vérification.

Cela a été un succès car les tests de construction et de vérification prenaient généralement environ 4 heures, donc la rupture de la construction signifiait que vous perdiez une demi-journée à faire du vrai travail. Inutile de dire que les développeurs ont utilisé les branches plus efficacement avant de les fusionner dans le tronc. Pour la plupart des développeurs, l'état d'esprit précédent était "Je vais simplement laisser le système de construction CI m'informer si mon code est cassé."


1

Une simple modification du système CI le ferait: toute modification qui rompt la construction est automatiquement annulée. Encore mieux, laissez le référentiel CI devenir une zone de transit, où les modifications ne sont transmises au référentiel faisant autorité que lorsque la version est verte. Des outils comme Gerrit peuvent vous aider ici.


3
Mais pour rendre cette tâche impossible "... gardez à l'esprit que je suis un développeur, pas un gestionnaire, et que je ne peux pas changer le processus ..."
SChepurin

@SChepurivotre processus est inefficace, vous avez décidé de changer le processus, point final. En tant que développeur, vous ne pourrez peut-être pas approuver la modification, mais vous pourrez toujours travailler à l'amélioration des processus.
oefe

1

Deux autres choses pourraient aider ici:

  • votre équipe peut-elle tester localement un CI construit? Si vous vérifiez que vous ne cassez pas la build - ou du moins ne la cassez pas de manière courante sans avoir à valider et déclencher la gestion et la colère de l'équipe.
  • il existe de nombreuses façons de définir des builds cassés selon la façon dont vous architecturez CI. Cela comprend la définition de cassé - dans le cadre d'un développement intensif, nous ne considérons pas l'échec des tests comme une pause, mais plutôt comme un autre objectif à atteindre.

Mais vous devriez vraiment regarder les branches.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.