Wie entschuldige ich mich, wenn Sie den nächtlichen Bau [geschlossen] gebrochen haben?

181

Mein erstes Commit in meinem Projekt führte dazu, dass der nächtliche Build gebrochen wurde und die Leute über mich hinweg waren, als wir uns der Veröffentlichung nähern. Ich möchte eine Entschuldigungs-E-Mail senden, die aufrichtig klingen sollte und gleichzeitig darauf hinweist, dass dies mein erstes Commit war und dies nicht mehr wiederholt werden würde.

Als nicht-englischer Muttersprachler habe ich Schwierigkeiten, die richtigen Wörter zu finden. Kann jemand bitte helfen?

Rajachan
quelle
99
Wenn der Build nie brach, würde ich anfangen, einen fehlerhaften Build-Prozess zu vermuten;)
Lazarus
6
Woher solltest du wissen, dass der Build gebrochen wurde?
65
Wie wäre es mit: "Es tut mir sehr leid, dass ich die Nachtarbeit abgebrochen habe. Wenn Sie mein Gehalt als Bestrafung einbehalten wollen, werde ich das Unternehmen nicht vor ein Arbeitsgericht bringen." Nein, nur ein Scherz - entschuldigen Sie sich nicht, so etwas passiert die ganze Zeit. Leute, die "überall" sind, sind begeisterte Psychos, die nicht wissen, wie man das System in den vorherigen Zustand zurückversetzt.
Jas
14
Ich habe den Build für meine ersten 10 Commits gebrochen! Mach dir
Niemand
135
Ich wünschte nur, ich hätte einen nächtlichen Build, um zu brechen ..
Max

Antworten:

306

Entschuldige dich nicht !

  • Den Bau einmal in einem blauen Mond zu brechen, ist keine große Sache und sollte niemals ein Show-Stopper sein.
  • Es ist die Schuld Ihres Managers, keine kontinuierlichen, automatisierten Builds zu konfigurieren.

Ich wette auch, dass Ihr Team den Joel-Test nicht besteht und keinen Build in einem Schritt erstellen kann.

Wenn ja, wäre dies eine andere Sache, für die Sie sich nicht entschuldigen sollten. In der Tat ist es ein Team-Anti-Pattern.

Jim G.
quelle
31
+1 Einverstanden! Entschuldige dich nicht. LERNEN Sie, was Sie falsch gemacht haben. Mach es nicht noch einmal, zumindest nicht so bald. Sei höflich, wenn die Leute "überall auf dir" sind. Lerne aus dem, was sie sagen (auch wenn es nur darum geht, wer ein Idiot ist und wer in Ordnung ist).
Peter K.
12
Nun, Sie können sich immer noch entschuldigen ... Aber ich bin ein bisschen überrascht, dass die Leute überall auf Ihnen sind. Wenn Sie neu im Team sind, sollte es keine Überraschung sein, dass Sie einen Fehler gemacht haben. Zumindest zeigt es, dass Sie etwas getan haben :)
Philippe
40
+1. Der ganze Zweck eines nächtlichen Builds ist es, Probleme so früh wie möglich zu erkennen, bevor sie mit einer Veröffentlichung losfahren. 95% der Entwickler haben während ihrer Karriere Fehler in Bezug auf die Sichtbarkeit gemacht. Die anderen 5% lügen.
Blrfl
26
Ich bin damit einverstanden, dass dies keine Entschuldigung auf der Ebene des "Fallens auf dem Schwert" erfordert, aber ich denke, dass dies eine Entschuldigung auf der Ebene des "Ups, mein schlechtes" erfordert. Nicht jedes "Es tut mir leid" muss böse sein.
Matthew Scouten
5
Ich bin mit dieser Prämisse überhaupt nicht einverstanden, es ist nichts Falsches an einer einfachen Entschuldigung "Es tut mir leid". Mir ist klar, dass ich es vermasselt habe und ich werde mein Bestes tun, um aus meinem Fehler zu lernen . Ich bin damit einverstanden, dass der beste Weg, sich selbst zu ändern, darin besteht, es nicht noch einmal zu tun, aber wenn es Sie interessiert, möchten Sie es möglicherweise nicht offen zeigen, um es anderen mitzuteilen, nicht jedes Mal, wenn Sie es vermasseln, aber er fühlte sich eindeutig schlecht es und es ist nichts falsch daran, sich zu entschuldigen.
Trufa
182

Bagels. Donuts. Bei einem Unternehmen, für das ich in der Vergangenheit gearbeitet habe, wird das Einchecken von fehlerhaftem Code oder das sonstige Beeinträchtigen von Kollegen in der Regel durch das Einbringen von entschuldigenden Lebensmitteln am nächsten Tag behoben.

Wir hatten eines Tages einen Typen, der eine Produktionsdatenbank in die Luft jagte, was für das gesamte Team massive Panik und eine späte Nacht verursachte. Am nächsten Tag grillte er Burger zum Mittagessen.

Ich liebe es, mich bei Kollegen zu entschuldigen. Leckere, leckere Entschuldigungen.

Dan Ray
quelle
83
+1 für "Ich liebe Entschuldigungen von Mitarbeitern. Lecker, lecker Entschuldigungen."
Jas
32
Die nächtliche Entwicklung zu unterbrechen ist eine Sache, aber die Produktionsdatenbank zu sprengen ist auf einer ganz anderen Ebene. Wenn ich das jemals tat, wünschte ich mir, das Grillen von Burgern wäre die schlimmste Strafe für mich.
maple_shaft
20
Sie können die Schuld fast schmecken.
Mike Speed
40
"Eine Produktionsdatenbank wegblasen" stellt mir alle möglichen lustigen Bilder in den Kopf, was genau mit der Datenbank passiert ist. Bei den meisten von ihnen hört jeder eine laute Explosion aus dem Serverraum. "Oh Gott, die Datenbank erreicht ein kritisches Volumen!" "Schnell! Senken Sie die Steuerstangen!" "Es ist zu spät, die Daten, sie ist zum Scheitern verurteilt!" BOOM
Carson Myers
7
drop database... Oh, die Kraft dieser zwei kleinen Wörter. Es war vor Jahren, aber ich erinnere mich noch gut;)
Leigh
80

Zwei Zitate für Sie:

Der Mann, der keine Fehler macht, macht normalerweise nichts. - William Connor Magee

Wer keine Fehler macht, ist nicht stark genug. - Wess Roberts

Ich stimme mit Jim G. , entschuldige dich nicht aber von ihm lernen und nicht den gleichen Fehler wieder machen ... halten Sie es trocken;)

Lazarus
quelle
9
Oder es gibt das allgemeinere Zitat von: "Wer ohne Sünde ist, wirft den ersten Stein". Wenn jemand, der jemals über das gebrochene Gebäude jammert, das Gebäude schon einmal gebrochen hat, sollte er nicht jammern
Richard
wie der zweite !!
Sufendy
1
Ich zitiere mich zu jedem Grad / Junior, den ich jemals betreut habe "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
Gute Anwendung des "DRY" -Prinzips ... :)
J. Allan
53

Entschuldige dich nicht, sondern repariere es so schnell wie möglich. Es ist okay, jeder bricht den Build mindestens einmal, in meiner letzten Firma war es so etwas wie ein Einweihungsritual. Wenn ein Teammitglied den Build kaputt machte, legten wir am Morgen vor seiner Ankunft ein Gummi-Entchen auf seinen Schreibtisch. Dies ließ ihn wissen, dass er den Build kaputt gemacht und ihn repariert hatte.

Wir nannten es das Continuous Integration Duckie und wenn du es für den Tag hättest, würden die Leute dich ärgern, aber es hat Spaß gemacht, nichts davon sollte gemein sein.

Wir haben so etwas wie einen gebrochenen Build genommen und daraus eine Teambuilding-Übung gemacht.

maple_shaft
quelle
2
+1: nicht nur, was sie interessiert - alles, was sie interessieren sollten . Du hast also nichts falsch gemacht - nur die Grenzen des Möglichen ein bisschen zu weit gezogen;). Sie sind wahrscheinlich auch die Person, die am besten in der Lage ist, das Problem zu beheben. Jeder tut dies immer wieder. Jeder lädt etwas zum Leben hoch, das nicht hätte verschwinden dürfen. Jeder verlässt die WHERE-Klausel in einer UPDATE-Anweisung einmal in seinem Leben. Es ist wichtig, wie Sie reagieren. Wo wir sind, neigen alle Entwickler dazu, sich zu schließen und sich zu weigern, darüber zu sprechen, wer individuell schuld war, wenn jemand danach fragt, es wird einfach behoben.
Tom Morgan
Das scheint eine wirklich gute Möglichkeit zu sein, mit Fehlern umzugehen.
Trufa
3
Kontinuierliche Integration Duckie , Hahahaha
AttackingHobo
43

"Es tut mir leid!" So entschuldige ich mich normalerweise, wenn ich den Build gebrochen habe. Es passiert. Aber wie andere bereits gesagt haben, ist dies eine Gelegenheit, Ihre Systeme zu verbessern, sodass eine Person nicht so einfach den Build für alle anderen aufbrechen kann.

Ich würde mich unter diesen Umständen nicht förmlich entschuldigen, aber wenn Sie tatsächlich der Meinung sind, dass eine förmlichere Entschuldigung angemessen ist, sollte Ihre Entschuldigung Folgendes tun:

  • Bedauern ausdrücken.
  • Nennen Sie das Problem.
  • Verantwortung übernehmen.
  • Wiedergutmachung leisten.
  • Rette das Gesicht.

Das heißt: "Es tut mir leid, dass ich Sie [bei der Übernahme der Verantwortung] belästigt habe, indem ich versehentlich [SAVE FACE] den Build abgebrochen habe [STATE THE PROBLEM]. Donuts sind morgen bei mir. [MAKE AMENDS]"

Jeder Teil ist in einer richtigen Entschuldigung notwendig; Wenn Sie das Problem nicht angeben, ist es unklar. Wenn Sie nicht bereuen, Verantwortung übernehmen und Wiedergutmachung leisten, fühlen sich die Menschen unaufrichtig. Der Gesicht rettende Teil ist der am meisten übersehene Teil einer Entschuldigung; Der Teil, der das Gesicht rettet, erinnert den Verletzten daran, dass Sie ein wertvoller Mitarbeiter sind, der manchmal Fehler macht, und kein Idiot (oder Saboteur!)

Zum Schluss noch ein paar Gedanken zum Build Breaking:

Ich arbeite im C # / Visual Basic-Compiler-Team. Natürlich ist Visual Studio heute ein so großes Projekt, dass es ein eigenes Team für die Verwaltung der Gebäudeinfrastruktur und einen riesigen Raum mit einer eigenen Klimaanlage hat. Als ich Mitte der neunziger Jahre als Praktikant anfing, war das Visual Basic-Build-Team ein Praktikant - ich - und ein Schrank voller Maschinen. Die Zeiten haben sich geändert!

Damals, vor der kontinuierlichen Integration und starken Eincheckprozessen, hatten Teams eine Reihe von Strafen, um den Build zu brechen. In einigen Teams bestand die Strafe darin, dass man jeden Tag bei der Arbeit einen lustigen Hut tragen musste, wenn man den Build brach, bis jemand anderes den Build brach. Wenn Sie in einigen Teams diesen Hut trugen, waren Sie dafür verantwortlich, die Richtigkeit des nächtlichen Builds zu überprüfen.

Das letzte bisschen klingt vielleicht grausam, aber es hat tatsächlich einen wertvollen Zweck erfüllt. Da fast jeder den Build zu der einen oder anderen Zeit brach, lernte schließlich das gesamte Team die Prozesse zur Überprüfung des nächtlichen Builds.

Eric Lippert
quelle
15

Entschuldige dich nicht. Es sind Ihre Mitarbeiter, die dafür verantwortlich sind, dass Sie Ihr erstes Commit nicht überprüft haben und kein schnelles Feedback-System für Builds wie einen Continuous Integration Server haben.

In meinem jetzigen Job haben wir die informelle Regel, dass jemand, der sich kurz vor dem Verlassen der Arbeit schleichend verpflichtet und sich herausstellt, dass er den Bau abbricht, am nächsten Tag Süßigkeiten / Kuchen / Getränke für das gesamte Team mitbringen muss. Aber wir haben eine kontinuierliche Integration, die uns tagsüber vor einem gebrochenen Build warnt. Und die Regel würde wahrscheinlich nicht für das erste Commit einer Person gelten.

Wie auch immer, eine formelle Entschuldigung ist wahrscheinlich ein bisschen zu viel.

guillaume31
quelle
Hervorragende Point-Peer-Reviews hätten dies auffangen sollen. Weil Sie tun Peer - Review - Änderungen , bevor sie zum Master / HEAD / default angelegt ist, nicht wahr?
Frank Shearar
11

Eine grundlegende Regel - wenn Sie sich irren, ADMIT IT: - | Sie müssen sich nicht entschuldigen. Jeder macht Fehler. Die Profis geben es zu. Das ist Teamwork. Die anderen Teammitglieder sollten sich zusammenreißen, um Ihnen dabei zu helfen. Wenn nicht, bitten Sie um Hilfe. Danach muss höchstens gesagt werden: Was können wir daraus lernen?

Sie sagen, eine erfolgreiche Ehe basiert auf drei kleinen Worten: "Ich habe mich geirrt".

Wenn jemand keinen Fehler macht, funktioniert er nicht, aber ein Fehler, aus dem man nicht lernt, sind zwei Fehler.

Mike Dunlavey
quelle
Ich denke, das ist eine großartige Antwort und viel besser als die "Entschuldige dich nicht", die die höchsten Stimmen hat. Sie können sich bei jedem dafür entschuldigen, dass er den Build gebrochen hat, aber er muss Ihnen auch ein bisschen Anmut zeigen. Sie sollten auch sagen: "Keine Sorge, wir haben es alle schon mal kaputt gemacht, schließlich ist es das, wofür es da ist." Solange Sie versuchen, es nicht noch einmal zu brechen, sollten sie damit cool sein. Wenn Sie alle ignorieren und den gleichen Fehler machen, ist das eine andere Geschichte.
Rocklan
6

Die beste Entschuldigung ist, die Pause schnell zu beheben

JaredPar
quelle
5

Wenn Ihr Unternehmen bereits über eine Möglichkeit verfügt, Ihre Buildänderungen zu testen, sind (A) Ihre Änderungen entweder fehlgeschlagen (Sie haben sie jedoch trotzdem eingecheckt) oder (B) sie waren erfolgreich (und Sie müssen einen neuen Testfall erstellen).

Wenn Ihre Kollegen ihre Änderungen sorgfältig testen und erwarten, dass der nächtliche Build unterbrochen wird, haben Sie (C) einen spröden Prozess (und Sie müssen Tests einführen, wie sie in Extreme Programming zu finden sind).

Es ist möglich, dass (D) Ihre Änderungen zu unvorhergesehenen Änderungen im Code von Bill geführt haben, die entweder bereits vor dem Build vorgenommen oder im selben Build wie Sie geändert wurden.

Abhängig davon, wie Sie und Ihr Unternehmen testen, würde ich mich von Fall zu Fall entschuldigen:

  • (A) Ich habe den Build-Test nicht bestanden, aber meine Änderungen eingecheckt. Entschuldigung, ich ändere meinen Prozess, damit ich es nicht wieder tun werde.
  • (B) Ich habe den Build-Test bestanden und JUnit-Test XYZtest.java hinzugefügt, um die Wahrscheinlichkeit eines erneuten Auftretens zu verringern.
  • (C) Da wir keinen Build-Testprozess haben, erstelle ich einen für meine Änderungen. Ich möchte mit Ihnen teilen, wie wir unseren Erstellungsprozess verbessern können.
  • (D) Ich werde mit Bill zusammen einen JUnit-Test XYZtest.java schreiben, um die Wahrscheinlichkeit eines erneuten Auftretens zu verringern.

Ich bin sicher, dass es ein (E) gibt, an das ich nicht gedacht habe.

Beachten Sie, dass ich sage "um die Wahrscheinlichkeit eines erneuten Auftretens zu verringern" und nicht "damit es nicht wieder vorkommt". Es wird wieder vorkommen. Sie können jedoch Ihren Prozess verbessern, um diese Möglichkeit zu verringern. Ich denke, das ist eines der Merkmale eines erfolgreichen Programmierers.

rajah9
quelle
2

Entschuldige dich nicht. Du bist ein Mensch und du wirst Fehler machen. Jeder wird den Build gelegentlich abbrechen, der Schlüssel ist, ihn einfach schnell zu reparieren.

Was die Leute betrifft, die über dich springen ... nun, ich bin gespannt, ob sie jemals einen Fehler geschrieben haben.

Corv1nus
quelle
2

Wie Sie dies angehen, hängt von der Atmosphäre in Ihrer Gruppe ab. Wenn es eine Schuldkultur ist, würde ich sehr vorsichtig sein, wenn ich mich entschuldige und wie du es machst. Wenn es eine kollaborative, positive Atmosphäre ist, dann ja, etwas in der Art von "Ich habe es vermasselt, es tut mir leid. Wie können wir dies in Zukunft vermeiden?" ist wohl eine gute idee.

In jedem Fall sollte eine solche Panne von einer Art Obduktion begleitet sein, um a) herauszufinden, wie es passiert ist und b) wie die Wahrscheinlichkeit eines erneuten Auftretens minimiert werden kann.

Ich kenne Ihre Struktur nicht (ich arbeite in einer ganz anderen Umgebung), aber letztendlich ist die Realität, dass Menschen gelegentlich Fehler machen und Dinge kaputt gehen. Sie lernen aus der Erfahrung und machen weiter.

Versuchung
quelle
2

Wenn Sie in meiner Umgebung den Build abbrechen, erhalten Sie eine gutmütige Rippung und einen witzigen Kometen. Ich bin mir nicht sicher, in welchem ​​englischsprachigen Land Sie sich befinden, aber es kann sein, dass Sie als nicht englischsprachiger Muttersprachler nicht den unterstreichenden Charakter der Kommentare erkennen.

Da ich als Senior-Entwickler von der anderen Seite bin, habe ich einmal einen Code-Review kommentiert, in dem festgestellt wurde, dass eine Art und Weise, x zu "saugen", nicht darauf zurückzuführen ist, dass der Code schlecht ist, sondern sich auf die Struktur des Projekts auswirkt. Es war mehr Kommentar für mich, dass ich das strukturelle Problem beheben muss. Erst später stellte ich fest, dass der Jr. Dev, obwohl ich wegen meiner ungenauen flippigen Rede sehr wütend auf ihn war.

Wiederholung
quelle
2

Äh. Sie erhalten das defekte Build-Token . Geben Sie die Tollwut an den nächsten glücklichen Empfänger weiter. Es passiert die ganze Zeit. Qualität ist wichtig, aber Fehler sind unvermeidlich. Repariere sie. Mach weiter. Schade, der nächste arme Kerl.

M. Tibbits
quelle
1
Ich habe das viel gesehen. Das andere ist, dass Sie sich um den nächtlichen Bau "kümmern" müssen, bis jemand anderes ihn kaputt macht. Dies bedeutet nicht, das Problem zu beheben, sondern herauszufinden, warum und wer es beheben sollte.
Stephen Darlington
1

Generell würde ich sagen:

Wenn Ihr Einchecken einen Compilerfehler verursacht, den Sie selbst bemerkt hätten, wenn Sie vor dem Einchecken ein "get latest" durchgeführt hätten, ist ein einfaches "whoops, my bad" in Ordnung. (Vor allem, wenn Sie am nächsten Morgen um 10 Uhr hereinspazieren, während alle entscheiden, auf welches Änderungsset zurückgespult werden soll.)

Wenn Ihr Einchecken zu allgemein unerwartetem Verhalten führt, auch zu Laufzeitfehlern, sollte es meines Erachtens nicht gegen Sie gerichtet werden. Es kommt mit dem Territorium. Solange das "Neueste" aller Benutzer in der Regel ihren Compilern bestanden hat, sollten die Benutzer wirklich keinen Fit auslösen (mit ein paar Ausnahmen wie dem Löschen einer Datenbank, dem Löschen der Serverkopie des Projekts und aller Änderungssätze oder sonstigem, was auch immer der Fall ist) dumm, dass Leute böswillige Absichten haben).

Morgan Herlocker
quelle
1

Das TEAM ist gescheitert.

Ihr Unternehmen benötigt mehr Codeüberprüfung für einen Entwickler, der zum ersten Mal einen Build durchführt.

Ich verstehe nur nicht, wie ein Team dies zulässt, ohne dass es eine Überprüfung durchführt und ein paar Zusicherungen gibt, dass Sie die Dinge richtig machen.

Es ist keine Entschuldigung, kurz vor der Veröffentlichung zu stehen, sondern ein besserer Grund, neuen Code noch einmal zu überprüfen.

Wenn Ihre Freigabe nicht einfach rückgängig gemacht werden kann, gibt es bei dieser Gruppe noch größere Probleme.

JeffO
quelle
0

Ich verstehe nicht, warum die Leute überall auf dir sind. Wenn das System gut eingerichtet ist, sollten sie in der Lage sein, Ihre Änderungen sehr schnell zu korrigieren.

Aber nochmal, wenn Sie einer der Typen sind, die die Fenster zerbrochen haben, dann ... kann ich nicht helfen. (Es ist unglaublich schwer, dies zu tun, bevor irgendjemand Fragen an MS stellt, aber ab und zu tut es jemand - und die gesamte QS des Unternehmens stoppt für einen Tag).

Und ja - entschuldige dich nicht. Sprechen Sie einfach mit Ihrem Vorgesetzten und lassen Sie ihn verstehen, dass Sie aus dem, was Sie getan haben, gelernt haben.

Subu Sankara Subramanian
quelle
0

Builds brechen die ganze Zeit. Bugs und Fehler sind eine Tatsache des Lebens, und deshalb sollten Sie einen Prozess haben, der die Auswirkungen von Bugs und Fehlern minimiert.

Wenn ein Build-Abbruch so groß ist, bedeutet dies, dass Ihr Prozess unterbrochen ist.

Sie sollten kontinuierliche Builds durchführen, keine nächtlichen Builds.

Christoffer Hammarström
quelle
+1 für "Wenn ein Build-Abbruch so groß ist, bedeutet dies, dass Ihr Prozess unterbrochen ist." Auf der anderen Seite müssen Sie sich immer noch mit dem fehlerhaften Prozess befassen, und das bedeutet, dass Sie alles tun, um zu vermeiden, dass der nächtliche Build unterbrochen wird, bis der Prozess verbessert ist.
Caleb
0

Besser eine späte Antwort als nie ...

Wie viele andere bereits gesagt haben, entschuldigen Sie sich nicht, dass Sie den Build abgebrochen haben. Geben Sie einfach zu, dass Sie es waren und machen Sie mit der Arbeit weiter. Dieses Zeug würde passieren, ob Sie da waren oder nicht, und niemand hat es verdient, deswegen schlecht behandelt zu werden. Menschen reagieren unter Druck schlecht. Wenn Sie also ruhig bleiben und einfach weiterarbeiten können, werden Sie auffallen, wenn es darauf ankommt. Mein Ratschlag für Menschen, die es schwer haben, ist, einfach die Defensive zu meiden, die Situation zu entschärfen, indem man die Leute wissen lässt, dass man entweder am Problem ist oder schnell um Rat bittet, wenn man feststeckt.

Persönlich sehe ich einen kaputten Build als Chance.

  • Wenn der Build abbricht und Sie nachweisen können, dass es Ihre Schuld ist, ist es wahrscheinlich, dass die kontinuierlichen Integrations- und Build-Prozesse ihre Arbeit erledigen. Dies ist eine gute Sache, da es Ihre Prozesse validiert. Wenn der Build niemals abbricht, würde ich mir Sorgen machen, dass etwas nicht stimmt.
  • Wenn Sie den Build auf eine häufig vorkommende Art und Weise unterbrochen haben und dies häufig vorkommt, fehlt möglicherweise etwas im CI-Prozess. Dies ist eine Gelegenheit, Ihre Prozesse zu verbessern, damit die allgemeinen Fehlerszenarien besser verwaltet werden können.
  • Wenn Sie über die Pflicht hinausgegangen sind und den Build wirklich mit einem obskuren Problem durcheinander gebracht haben, haben Sie die Möglichkeit, etwas Neues zu erfahren, das möglicherweise wichtig genug ist, um eine Warnung an den Rest des Teams auszulösen.

Ich sage also, dass ein gelegentlicher Abbruch des Builds bedeutet, dass die Leute ihre Arbeit machen. Sicher, Sie haben vielleicht einen Fehler gemacht, aber wenn Sie ihn als Gelegenheit zum Lernen nutzen, machen Sie Ihren Job einfach, indem Sie lernen, es beim nächsten Mal besser zu machen.

S.Robins
quelle
-1

Sagen Sie ihnen, dass sie CI-Builds beim Einchecken benötigen. Auf diese Weise müsstest du nicht bis zum nächsten Abend warten, um zu wissen, dass es kaputt ist. JA!!! Sagen Sie ihnen, es ist der Prozess, der falsch ist, sonst nichts. Sie haben gerade eine Lücke in ihrem System festgestellt .

Aber ja, stellen Sie sicher, dass Sie das Problem beheben. Keine große Sache. Es ist nicht in Produktion. Nur eine wertlose Nacht.

Issa Fram
quelle
-2

Eine übliche Praxis in meiner Firma ist:

  • Geschrei "Ich war es nicht!" (sonst normalerweise CVS / SVN Beweise)
  • Ein T-Shirt mit der Aufschrift "my-userlogin ist Schuld!" (ja, 50% unserer Entwickler besitzen so ein Shirt)
  • Behauptend, dass es in der lokalen Sendbox funktioniert und alle Tests gut bestanden haben

Mein Unternehmen hat auch eine gute Möglichkeit, mit einem solchen "Vorfall" umzugehen:

Robert Heine
quelle
-2
  • Ich würde mich nicht entschuldigen.

  • Ich würde CI lead dafür beschuldigen, dass ich einen fehlerhaften Build begangen habe.

  • Es sollte einen CI-Prozess geben, mit dem Entwickler daran gehindert werden können, fehlerhaften Code zu schreiben.

  • Wenn die lokale Erstellung fehlschlägt, darf der Build-Server nicht betreten werden.

CodeART
quelle
1) Nicht alle Projekte sind für eine kontinuierliche Integration eingerichtet. Es ist schön zu haben und kann in Situationen wie den OPs helfen, aber es ist alles andere als selbstverständlich. 2) Es tut nie weh, sich zu entschuldigen, auch wenn es nicht wirklich eine große Sache ist, selbst wenn es Werkzeuge gibt, die das Problem hätten verhindern können. 3) Jemand anderem die Schuld an einem von Ihnen verursachten Problem zu geben, unabhängig davon, ob es wirklich Ihre Schuld ist oder nicht, ist eine miese Idee.
Caleb
Hier gibt es zwei Probleme: 1 - fehlerhafter Code auf dem lokalen Computer. 2 - fehlerhafter Code auf einem Buildserver. Das erste Problem ist sehr gering, da alle Entwickler Fehler machen. Änderungen können rückgängig gemacht werden und haben keine Auswirkungen auf das System oder die Abteilung. Das zweite Problem wird wahrscheinlich eine viel größere negative Auswirkung auf das System und die Abteilung haben.
CodeART
-2

Obwohl ich denke, dass eine Entschuldigung vorliegen kann, sagen Sie bitte nicht: "Ich werde dafür sorgen, dass dies nicht noch einmal passiert." Weil es so sein wird. Und wenn doch, wird es dich beißen.

Pieter B
quelle
-2

Wenn Sie an einem Open Source-Projekt arbeiten,

sag einfach "Sorry, ich habe den Build abgebrochen. Vielleicht war ich zu müde!"

und füge es als Github-Kommentar hinzu.

Das liegt daran, dass viele Open-Source-Entwickler um Mitternacht Code schreiben.

linquize
quelle