Comment faire des excuses quand vous avez cassé la construction nocturne [fermé]


181

Mon premier engagement dans mon projet a abouti à la destruction de la construction nocturne et les gens sont partout sur moi alors que nous approchons de la sortie. Je veux envoyer un courriel d'excuses qui devrait sembler sincère et indiquer en même temps qu'il s'agissait de mon premier engagement et que cela ne se reproduirait plus.

Étant non anglophone, j'ai du mal à trouver les mots corrects. Puis-je avoir une aide s'il vous plait?


99
Si la construction ne se cassait jamais, je commencerais à soupçonner un processus de construction cassé;)
Lazarus

6
Comment avez-vous pu savoir que la construction était cassée?

65
Que diriez-vous de: "Je suis vraiment désolé d’avoir brisé la nuit. Si vous voulez retenir mon salaire en guise de punition, je ne prendrai pas la société au tribunal de l’emploi". Nah, je plaisante - ne vous excusez pas, ce genre de choses se passe tout le temps. Les gens qui sont "partout sur vous" sont des psychologues qui ne savent pas comment restaurer correctement le système à son état antérieur.
Jas

14
J'ai cassé la construction de mes 10 premiers commits! Ne vous inquiétez pas
Personne

135
Je voudrais juste avoir une construction nocturne à casser ..
Max

Réponses:


306

Ne t'excuse pas !

  • Briser la construction une fois dans une lune bleue n’est pas une grosse affaire et ne devrait jamais être un spectacle.
  • C'est la faute de votre responsable pour ne pas configurer des builds automatisés et continus.

De plus, je parie que votre équipe échoue au test de Joel et ne peut pas construire en une étape.

Si tel est le cas, ce serait une autre chose pour laquelle vous ne devriez pas vous excuser. En effet, c'est un anti-pattern d'équipe.


31
+1 d'accord! Ne t'excuse pas. Apprenez ce que vous avez fait de mal. Ne recommencez pas, du moins pas bientôt. Soyez poli quand les gens sont "partout sur vous". Apprenez de ce qu'ils disent (même si c'est juste qui est un con et qui va bien).
Peter K.

12
Eh bien, tu peux encore t'excuser ... Mais je suis un peu surpris que les gens soient partout sur toi. Si vous êtes nouveau dans l'équipe, il ne devrait pas être une telle surprise que vous ayez commis une erreur. Au moins, ça montre que tu as fait quelque chose :)
Philippe

40
+1 Le but de la construction nocturne est d’attraper les problèmes le plus tôt possible et avant qu’ils ne partent avec une sortie. 95% des développeurs ont commis des erreurs de grande visibilité au cours de leur carrière. Les 5% restants mentent.
Blrfl

26
Bien que je convienne que cela ne nécessite pas d'excuses de niveau "tomber sur l'épée", je pense que cela nécessite des excuses de niveau "oops, my bad". Tous les 'Je suis désolé' ne doivent pas nécessairement être abjectes.
Matthew Scouten

5
Je ne suis pas du tout d'accord avec ce postulat, il n'y a rien de mal à de simples excuses "je suis désolé", je me rends compte que je me trompe et que je ferai de mon mieux pour tirer les leçons de mon erreur . Je conviens que le meilleur moyen de * modifier * vous-même est de ne pas le refaire, mais si cela vous intéresse, vous pourriez ne pas le montrer ouvertement pour que les autres sachent, pas à chaque fois que vous bousillez, mais il se sentait clairement mal à propos de et il n’ya rien de mal à s’excuser.
Trufa

182

Bagels Donuts. Etc. Dans une entreprise pour laquelle j’ai travaillé par le passé, la vérification du code erroné ou la perturbation des collègues est généralement résolue par l’apport de produits alimentaires excuses le lendemain.

Un jour, un gars a explosé dans une base de données de production, provoquant une panique massive et une soirée tardive pour l’ensemble de l’équipe. Le lendemain, il a grillé des hamburgers pour le déjeuner.

J'adore les excuses de mes collègues. Savoureux, savoureux excuses.


83
+1 pour "J'aime les excuses de mes collègues. Des excuses savoureuses et savoureuses."
Jas

32
Rompre la génération de développement nocturne est une chose, mais détruire la base de données de production est à un tout autre niveau. Si jamais je le faisais, je souhaite que griller des hamburgers soit la pire de ma punition.
maple_shaft

20
Vous pouvez presque goûter la culpabilité.
Mike Speed

40
"Souffler une base de données de production" me donne toutes sortes d'images hilarantes sur ce qu'il est advenu de la base de données. Dans la plupart des cas, tout le monde entend une forte explosion de la salle des serveurs. "Oh mon dieu, la base de données atteint un volume critique!" "Vite! Baisse les tiges de contrôle!" "Il est trop tard, les données, elle est condamnée!" BOOM
Carson Myers

7
drop database... Oh le pouvoir de ces deux petits mots. C'était il y a des années, mais je m'en souviens bien;)
Leigh

80

Deux citations pour vous:

L'homme qui ne fait pas d'erreur ne fait généralement rien .-- William Connor Magee

Celui qui ne fait pas d'erreur ne fait pas assez d'efforts .-- Wess Roberts

Je suis d'accord avec Jim G. , ne vous excusez pas, mais apprenez-en et ne faites plus la même erreur ... gardez-le au sec;)


9
Ou il y a la citation plus générale de: "que celui qui est sans péché jette la première pierre" Si celui qui gémit à propos de la construction cassée a déjà cassé la construction avant, il ne devrait pas être gémissant
Richard

comme le second !!
Sufendy

1
Moi - même à chaque Grad cite / junior que j'ai jamais servi de mentor, "I expect you to make lots of mistakes. Own up to them, accept them, and learn from them. If you never make mistakes, you'll never really learn anything".
S.Robins

Belle utilisation du principe "DRY" ... :)
J. Allan

53

Ne vous excusez pas, corrigez-le le plus rapidement possible. Tout va bien, tout le monde casse la construction au moins une fois. Dans ma dernière entreprise, c’était un rituel d’initiation. Lorsqu'un membre de l'équipe cassait le gabarit, nous mettions un duck en caoutchouc sur son bureau le matin avant son arrivée. Cela lui a permis de savoir qu'il avait brisé le gabarit et qu'il le réparerait.

Nous l'appelions le Duckie d'Intégration Continue et quand vous l'aviez pour la journée, les gens vous taquineraient, mais c'était amusant, rien de tout cela n'était censé être mesquin.

Nous avons pris quelque chose comme une construction brisée et l'avons transformé en exercice de renforcement d'équipe.


2
+1: pas seulement ce qui leur tient à cœur - tout ce dont ils devraient se soucier. En tant que tel, vous n’avez rien fait de mal: vous n’avez fait qu’un peu exagérer les limites du possible;). Vous êtes probablement aussi la personne la mieux placée pour y remédier. Tout le monde le fait de temps en temps. Tout le monde télécharge quelque chose à vivre qui n'aurait pas dû disparaître. Tout le monde laisse la clause WHERE dans une instruction UPDATE une fois dans sa vie. C'est la façon dont vous réagissez qui est important. Où que nous soyons, tous les développeurs ont tendance à fermer, refusant de dire qui était individuellement responsable si quelqu'un le demande, cela se résout simplement.
Tom Morgan

Cela semble être un très bon moyen de gérer les erreurs.
Trufa

3
Intégration continue Duckie , Hahahaha
AttackingHobo

43

"Désolé mon mauvais!" C'est comme ça que je m'excuse habituellement quand j'ai cassé la construction. Ça arrive. Mais comme d’autres l’ont dit, c’est une occasion d’améliorer vos systèmes afin qu’une personne ne puisse pas casser aussi facilement la construction pour les autres.

Je ne ferais pas d'excuses officielles dans ces circonstances, mais si vous estimez réellement que des excuses plus formelles sont appropriées, alors vos excuses devraient faire ce qui suit:

  • Exprimer un regret.
  • Indiquer le problème.
  • Prendre la responsabilité.
  • Faire amende honorable.
  • Sauver la face.

C’est-à-dire: "Je suis désolé [EXPRESS REGRET] de vous avoir dérangé [PRENEZ RESPONSABILITÉ] en cassant accidentellement [SAVE FACE]."

Chaque partie est nécessaire dans des excuses appropriées; si vous ne déclarez pas le problème, il n'est pas clair. Si vous n'exprimez pas de regrets, prenez des responsabilités et ne corrigez rien, les gens se sentiront comme si vous n'étiez pas sincères. La partie qui sauve la face est la partie la plus négligée des excuses; la partie qui sauve des visages est ce qui rappelle à la partie lésée que vous êtes un collègue précieux qui fait parfois des erreurs et non un idiot (ou un saboteur!)

Enfin, quelques réflexions sur la rupture de construction:

Je travaille sur l’équipe du compilateur C # / Visual Basic. Bien entendu, Visual Studio est aujourd'hui un projet tellement gigantesque qu'il dispose d'une équipe propre pour gérer l'infrastructure de construction et d'une vaste salle avec son propre système de climatisation dédié. Au milieu des années 90, lorsque j'ai commencé à travailler comme stagiaire, l'équipe de compilation de Visual Basic était composée d'un stagiaire - moi - et d'un placard rempli de machines. Les temps ont changé!

À une époque antérieure à l'intégration continue et à la mise en place de processus d'enregistrement robustes, les équipes se voyaient infliger diverses pénalités pour avoir rompu le build. Sur certaines équipes, la pénalité était que, si on cassait la carrure, il fallait porter un drôle de chapeau tous les jours au travail jusqu'à ce que quelqu'un d'autre casse la carrure. Sur certaines équipes, si vous portiez ce chapeau, il vous incombait de vérifier que la construction de nuit était correcte.

Ce dernier geste semble peut-être cruel, mais il a en fait servi un objectif précieux. Étant donné que presque tout le monde a cassé la construction à un moment ou à un autre, toute l'équipe devait éventuellement apprendre les processus de vérification de la construction nocturne.


15

Ne t'excuse pas. Ce sont vos collègues qui sont à blâmer pour ne pas avoir examiné votre premier commit et ne pas avoir un système de retour rapide pour les builds comme un serveur d’intégration continue.

Dans mon poste actuel, nous appliquons une règle informelle voulant que quelqu'un qui s'engage sournoisement juste avant de quitter son travail et finisse par casser le modèle doit apporter des bonbons / des gâteaux / des boissons à toute l'équipe le lendemain. Mais nous avons une intégration continue qui nous prévient d'une construction brisée pendant la journée. Et la règle ne s'appliquerait probablement pas au premier commit de quelqu'un.

Quoi qu'il en soit, un courrier officiel d'excuses est probablement un peu trop.


Excellent point - l'examen par les pairs devrait l'avoir compris. Parce que vous effectuez des révisions par les pairs avant qu'elles ne soient appliquées à master / HEAD / default, non?
Frank Shearar

11

Une règle fondamentale - quand vous vous trompez, ADMET IT: - | Vous n'êtes pas obligé de vous excuser. Tout le monde fait des erreurs. Les pros l'admettent. C'est du travail d'équipe. Les autres membres de l’équipe devraient s’unir pour vous aider. S'ils ne le font pas, DEMANDEZ de l'aide. Ce qu’il faut en dire au plus, c’est: que pouvons-nous en apprendre?

Ils disent qu'un mariage réussi repose sur trois petits mots: "j'avais tort".

Si quelqu'un ne commet pas une erreur occasionnelle, il ne travaille pas, mais une erreur dont on ne tire pas les leçons est deux erreurs.


Je pense que c'est une excellente réponse et bien meilleure que celle du "Ne vous excusez pas" qui a le plus grand nombre de voix. Vous pouvez présenter des excuses à tout le monde pour avoir rompu le build, mais ils doivent également vous montrer un peu de grâce. Ils devraient également dire "ne vous inquiétez pas, nous l'avons tous brisé avant, après tout, c'est pour cela qu'il est là". Tant que vous essayez de ne pas le casser encore, ils devraient être cool avec ça. Si vous ignorez tout le monde et faites la même erreur, alors l'histoire est différente.
Rocklan


5

Si votre société dispose déjà d'un moyen de tester vos modifications de génération, alors (A) vos modifications ont échoué (mais vous les avez archivées quand même) ou (B) elles ont réussi (et vous devez créer un nouveau scénario de test).

Si vos collègues testent avec précaution leurs modifications et s’attendent à trouver des failles dans la construction nocturne, alors (C) vous avez un processus fragile (et vous devez introduire des tests comme ceux de la programmation extrême).

Il est possible que (D) vos modifications aient provoqué des modifications imprévues dans le code de Bill qui étaient déjà en place ou ont été modifiées sur le même build que le vôtre.

En fonction de la manière dont vous et votre entreprise testez, je m'excuserais au cas par cas:

  • (A) J'ai échoué au test de construction, mais j'ai archivé mes modifications. Désolé, je suis en train de changer mon processus afin que je ne recommence plus.
  • (B) J'ai réussi le test de construction et ajouté le test JUnit XYZtest.java pour réduire les risques de récurrence.
  • (C) Comme nous n'avons pas de processus de test de construction, j'en crée un pour mes modifications. Je voudrais partager avec vous comment nous pouvons améliorer notre processus de construction.
  • (D) Je vais travailler avec Bill pour écrire un test JUNit XYZtest.java afin de réduire les risques de récurrence.

Je suis sûr qu'il y a un (E) auquel je n'ai pas pensé.

Notez que je dis "pour réduire les risques de récurrence" plutôt que "pour que cela ne se reproduise plus". Cela se reproduira. Mais vous pouvez améliorer votre processus pour réduire cette possibilité. Je pense que c'est l'une des marques d'un programmeur gagnant.


2

Ne t'excuse pas. Vous êtes humain et vous allez faire des erreurs. Tout le monde va casser la construction de temps en temps, la clé est de le réparer rapidement.

En ce qui concerne les gens qui sautent partout sur vous ... eh bien, je suis curieux de savoir s’ils ont déjà écrit dans un bogue.


2

Cela dépend de l’atmosphère de votre groupe. Si c'est une culture du blâme, je ferais très attention à vous excuser et à la façon dont vous le faites. Si c'est une atmosphère de collaboration positive, alors oui, quelque chose du genre "je me suis trompé, je suis désolé. Comment pouvons-nous éviter cela à l'avenir?" C'est probablement une bonne idée.

Dans tous les cas, une telle situation devrait être accompagnée d'une sorte d'autopsie pour a) découvrir comment cela s'est passé et b) comment minimiser les risques que cela se reproduise.

Je ne connais pas bien votre structure (je travaille dans un environnement très différent), mais au final, la réalité est que parfois, les gens font des erreurs et que des choses se cassent. Vous apprenez de l'expérience et continuez.


2

Dans mon environnement, si vous cassez la construction, vous obtiendrez une bonne nervure et un cométaire plein d’esprit. Je ne suis pas sûr du pays anglophone dans lequel vous vous trouvez, mais il se peut que vous n'obteniez pas la nature soulignée des commentaires en tant que non anglophone.

Étant de l'autre côté en tant que développeur senior, j'ai un jour commenté sur une révision de code qu'une manière de faire x "sucait" pas parce que le code était mauvais mais plutôt à la structure du projet. C’était plus un commentaire pour moi-même que je devais résoudre le problème structurel. Ce n’est que plus tard que j’ai découvert que Jr Dev était bien fâché contre lui à cause de mon discours inexact et désinvolte.


2

Hum Vous obtenez le jeton de construction cassé . Transmettez la rage au prochain destinataire chanceux. Arrive tout le temps. La qualité est importante, mais les erreurs sont inévitables. Répare les. Passez. Honte au prochain pauvre gars.


1
J'ai souvent vu ça. L'autre est que vous devez "soigner" la construction nocturne jusqu'à ce que quelqu'un d'autre la casse. Cela ne signifie pas réparer le problème, mais déterminer pourquoi et qui devrait le réparer.
Stephen Darlington

1

En règle générale, je dirais:

Si votre archivage provoque une erreur du compilateur, vous vous seriez attrapé si vous aviez fait une "obtention du dernier" avant l'enregistrement, un simple "whoops, my bad" est dans l'ordre. (surtout si vous vous promenez le lendemain matin à 10 heures, pendant que tout le monde décide du changement de groupe vers lequel revenir)

Si votre archivage provoque un comportement inattendu général, même des erreurs d’exécution, je ne pense pas que cela devrait vous être reproché. Il vient avec le territoire. Tant que tous les utilisateurs reçoivent les informations les plus récentes, leurs compilateurs ne doivent pas être pris au dépourvu . bête que les gens doivent assumer une intention malveillante).


1

Le team a échoué.

Votre entreprise a besoin de plus de révision de code sur un développeur effectuant une construction initiale.

Je ne vois tout simplement pas comment une équipe permet que cela se poursuive sans qu'elle procède à un examen et offre certaines garanties en cours de route que vous agissez correctement.

Être près du temps de publication n'est pas une excuse, mais une meilleure raison de vérifier le nouveau code.

Si votre version ne peut pas être facilement annulée, il existe des problèmes encore plus graves avec ce groupe.


0

Je ne comprends pas pourquoi les gens sont partout sur vous. Si le système est bien configuré, il devrait pouvoir extraire vos modifications et les corriger très rapidement.

Mais encore une fois, si vous êtes un de ces gars qui ont cassé la construction de fenêtres, alors ... je ne peux pas vous aider. (C'est incroyablement difficile à faire - avant que quiconque ne s'interroge sur la philosophie de MS, mais de temps en temps, quelqu'un le fait - et le contrôle qualité de toute l'entreprise s'arrête un jour).

Et oui - ne t'excuse pas. Parlez simplement avec votre responsable et faites-lui comprendre que vous avez appris de ce que vous avez fait.


0

Construit la pause tout le temps. Les bugs et les erreurs sont une réalité de la vie, et c'est pourquoi vous devriez avoir un processus qui minimise les effets des bugs et des erreurs.

Si une rupture de construction est un si gros problème, cela signifie que votre processus est interrompu.

Vous devriez faire des constructions continues, pas des constructions nocturnes.


+1 pour "si une rupture de construction est une si grosse affaire, cela signifie que votre processus est cassé." D'un autre côté, vous devez toujours gérer le processus interrompu, ce qui signifie que vous devez faire tout votre possible pour éviter de rompre la construction nocturne jusqu'à ce que le processus soit amélioré.
Caleb

0

Mieux vaut une réponse tardive que jamais ...

Comme beaucoup d’autres l’ont dit, ne vous excusez pas pour cette erreur. Admettez simplement que c'était vous et continuez votre travail. Cela arriverait que vous soyez là ou pas, et personne ne mérite d’être mal traité à cause de cela. Les gens réagissent mal sous la pression. Par conséquent, si vous parvenez à rester calme et à vous consacrer au travail, vous vous démarquerez lorsque cela sera important. Mon conseil, lorsque les gens vous donnent du fil à retordre, est tout simplement d’éviter d’être sur la défensive, de désamorcer la situation en indiquant aux gens que vous êtes sur le point de résoudre le problème ou que vous cherchez rapidement conseil si vous vous trouvez coincé (e).

Personnellement, je vois une construction cassée comme une opportunité.

  • Si la construction échoue et que vous pouvez prouver que c'est de votre faute, cela montrera probablement que les processus d'intégration continue et de construction font leur travail. C'est une bonne chose, car cela valide vos processus. Si la construction ne casse jamais, je crains que quelque chose ne va pas.
  • Si vous avez cassé la construction de manière assez commune et que cela arrive souvent, il se peut que quelque chose manque dans le processus de CI. C'est l'occasion d'améliorer vos processus afin de mieux gérer les scénarios de défaillance courants.
  • Si vous avez dépassé vos attentes et que vous avez vraiment gâché la construction avec un problème obscur, vous avez alors la possibilité d'apprendre quelque chose de nouveau qui pourrait être suffisamment important pour déclencher un avertissement au reste de l'équipe.

Donc, ce que je dis, c'est que casser la construction signifie parfois que les gens font leur travail. Bien sûr, vous avez peut-être commis une erreur, mais si vous l'utilisez comme une opportunité d'apprendre, vous faites votre travail simplement en apprenant à le faire mieux la prochaine fois.


-1

Dites-leur qu'ils ont besoin de versions de CI par enregistrement. De cette façon, vous n’auriez pas à attendre la nuit pour savoir que c’est cassé. OUI!!! Dites-leur que c'est le processus qui ne va pas, rien d'autre. Vous venez d'identifier une lacune dans leur système.

Mais oui, assurez-vous de le réparer. Pas un gros problème. Ce n'est pas en production. Juste une nuit sans valeur.


-2

Une pratique habituelle dans mon entreprise est:

  • Crier "ce n'était pas moi!" (généralement, preuves CVS / SVN sinon)
  • Vêtu d’un t-shirt portant la mention "my-userlogin ist Schuld!" (oui, 50% de notre développeur possède une telle chemise)
  • Affirmer que cela fonctionne dans la sendbox locale et que tous les tests ont réussi

Mon entreprise a également un bon moyen de gérer un tel "incident":


-2
  • Je ne m'excuserais pas.

  • Je voudrais blâmer le responsable de CI pour m'avoir permis de valider une construction brisée.

  • Un processus de CI doit être mis en place pour empêcher les développeurs de valider du code erroné.

  • Si la génération locale échoue, l'accès au serveur de génération ne doit pas être autorisé.


1) Tous les projets ne sont pas configurés pour une intégration continue. C'est bien d'avoir, et ça peut aider avec des situations comme les PO, mais c'est loin d'être acquis. 2) Il n’est jamais mauvais de s’excuser, même si ce n’est pas vraiment grave, même s’il existe des outils qui auraient pu prévenir le problème. 3) Blâmer quelqu'un d'autre pour un problème que vous avez causé, que ce soit vraiment de votre faute ou non, est une mauvaise idée.
Caleb

Il y a deux problèmes ici: 1 - code erroné sur la machine locale. 2 - code cassé sur un serveur de construction. Le premier problème est très mineur car tous les développeurs font des erreurs. Les modifications peuvent être annulées et il n'y aura aucun impact sur le système ou le service. Le deuxième problème risque d'avoir un impact négatif beaucoup plus grand sur le système et le ministère.
CodeART

-2

Bien que je pense que des excuses peuvent être en place, ne dites pas s'il vous plaît: "Je ferai en sorte que cela ne se reproduise plus." Parce que ça va. Et si cela se produit, il vous mordra.


-2

Si vous travaillez sur un projet open source,

dites simplement "Désolé, je me suis cassé la construction. Peut-être que j'avais trop sommeil!"

et l'ajouter comme commentaire de github.

C'est parce que beaucoup de développeurs open source écrivent du code pendant minuit.

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.