ナイトリービルドが壊れたときに謝る方法[終了]

私のプロジェクトで最初にコミットした結果、ナイトリービルドが壊れてしまい、リリースが近づいているので人々は私を取り囲んでいます。私は誠実に聞こえると同時に、これが私の最初のコミットであり、これがこれ以上繰り返されないことをほのめかす謝罪メールを送信したいと思います。

英語が母国語ではないので、正しい単語を見つけるのに苦労しています。誰か助けてくれますか？

謝らないで！

• ブルームーンで一度ビルドを壊すことは大したことではなく、決してショーストップになるべきではありません。
• 継続的な自動ビルドを構成しないことは、マネージャーの責任です。

また、あなたのチームは「ジョエルテスト」に失敗し、1ステップでビルドを作成することはできません。

もしそうなら、これはあなたが謝罪すべきではないもう一つのことでしょう。実際、それはチームのアンチパターンです。

ベーグル。ドーナツ。過去に働いていたある会社で、壊れたコードをチェックインするか、そうでなければ同僚の混乱を引き起こすことは、一般に翌日謝罪食品を持ち込むことによって解決されます。

ある日、ある男が実稼働データベースを吹き飛ばし、チーム全体に大規模なパニックと深夜をもたらしました。翌日、彼は昼食のためにハンバーガーを焼きました。

同僚の謝罪が大好きです。おいしい、おいしいおaび。

あなたのための2つの引用符：

間違いを犯さない人は通常何もしません。--ウィリアム・コナー・マギー

間違いを犯さない人は誰も十分に努力していません。

私はジムGに同意します。謝罪せずに、そこから学び、同じ間違いを二度としないでください。

謝るのではなく、できるだけ早く修正してください。でも、大丈夫です、誰もが少なくとも一度はビルドを壊します。私の最後の会社では、それは開始儀式のようなものでした。チームのメンバーがビルドを壊したとき、彼が来る前の朝に彼の机の上にゴム製のダッキーを置きます。

私たちはそれを継続的統合ダッキーと呼び、人々があなたをからかう日のためにそれを持っていたが、それはすべて楽しかったです、それのどれも意気揚々とされるべきではありませんでした。

壊れたビルドのようなものを取り上げて、チームビルディングの演習に変えました。

「ごめんなさい！私の悪い！」ビルドを壊したときに私が通常謝る方法です。それは起こります。しかし、他の人が言ったように、これはシステムを改善する機会であり、ある人が他の人のビルドを簡単に破ることができないようにします。

これらの状況では正式な謝罪はしませんが、実際により正式な謝罪が適切であると感じた場合、謝罪は次のことを行う必要があります。

• 明白な後悔。
• 問題を述べてください。
• 責任を取ります。
• 補正を行います。
• 面目を保ちます。

つまり、「[SAVE FACE]が誤ってビルドを壊して[SAVE FACE]して[TAKE RESPONSONIBILITY]をご迷惑をおかけして申し訳ございません[EXPRESS REGRET]。

適切な謝罪には各部分が必要です。問題を述べなければ、それは不明瞭です。後悔を表明せず、責任を負い、償いをしなければ、人々はあなたが不誠実だと感じます。顔を保存する部分は謝罪の最も見過ごされている部分です。顔を保存する部分は、負傷した当事者に、あなたは時として間違いを犯す価値のある同僚であり、バカ（または妨害者ではない）であることを思い出させます。

最後に、ビルドの中断に関するいくつかの考え：

私はC＃/ Visual Basicコンパイラチームで働いています。もちろん、今日のVisual Studioは非常に大規模なプロジェクトであり、ビルドインフラストラクチャを管理するだけのチームと、専用の空調システムを備えた巨大な部屋があります。1990年代半ばにインターンとして始めたとき、Visual Basicビルドチームは1つのインターンであり、私であり、クローゼットでいっぱいのクローゼットでした。時が変わった！

継続的な統合と強力なチェックインプロセスの前の時代には、チームはビルドを破ることに対してさまざまなペナルティを課せられていました。一部のチームでは、ビルドを壊した場合、誰かがビルドを壊すまで職場で毎日面白い帽子を着用しなければならないというペナルティがありました。一部のチームでは、その帽子をかぶっていた場合、ナイトリービルドが正しいことを確認する責任がありました。

その最後のビットは残酷かもしれませんが、実際には貴重な目的を果たしました。ほとんどすべての人が一時的にビルドを中断したため、最終的にチーム全体が夜間ビルドを検証するプロセスを学習します。

謝らないで 最初のコミットをレビューせず、継続的インテグレーションサーバーのようなビルドのための迅速なフィードバックシステムを持っていないことを非難するのは同僚です。

私の現在の仕事では、仕事を辞める直前にこっそりとコミットし、ビルドを壊すことが判明した人は、翌日、チーム全体にキャンディー/ケーキ/ドリンクを持ち込む必要があるという非公式のルールがあります。しかし、日中に壊れたビルドを警告する継続的な統合があります。そして、ルールはおそらく誰かの最初のコミットには適用されないでしょう。

とにかく、謝罪の正式なメールはおそらく少し多すぎる。

基本的なルール-あなたが間違っている場合、それを認める：-| 謝罪する必要はありません。誰でも間違いはある。プロは認めています。それがチームワークです。他のチームメンバーは、あなたを支援するために協力し合うべきです。そうでない場合は、助けを求めてください。後に言わなければならないことはほとんどです-それから何を学ぶことができますか？

彼らは、成功した結婚は3つの小さな言葉に基づいていると言います-「私は間違っていました」。

誰かが偶発的な間違いをしない場合、彼らは働いていませんが、人が学ばない間違いは2つの間違いです。

最高の謝罪は、休憩をすぐに修正することです

あなたの会社がすでにビルドの変更をテストする方法を持っている場合、（A）変更は失敗しました（しかし、とにかくチェックしました）または（B）成功しました（そして新しいテストケースをビルドする必要があります）。

同僚が変更内容を慎重にテストし、ナイトリービルドの中断を見つけると予想される場合、（C）プロセスが脆弱になります（エクストリームプログラミングで見られるようなテストを導入する必要があります）。

D

あなたとあなたの会社がどのようにテストするかに応じて、私はケースバイケースで謝罪します：

• （A）ビルドテストに失敗しましたが、変更をチェックインしました。申し訳ありませんが、プロセスを変更しているため、二度と行いません。
• （B）ビルドテストに合格し、JUnitテストXYZtest.javaを追加して、再発生の可能性を減らしました。
• （C）ビルドテストプロセスがないため、変更のために作成しています。ビルドプロセスを改善する方法をご紹介します。
• （D）Billと協力して、JUnitテストXYZtest.javaを作成し、再発生の可能性を減らします。

私が考えていない（E）があると確信しています。

「再発しないように」ではなく、「再発の可能性を減らすため」と言っていることに注意してください。再び起こります。ただし、プロセスを改善してその可能性を減らすことができます。それは、勝者のプログラマーのマークの1つだと思います。

謝らないで あなたは人間であり、間違いを犯します。誰もが時々ビルドを壊すでしょう、キーはただそれを素早く修正することです。

あなたの周りを飛び回る人々については...まあ、彼らがバグを書いたことがあるかどうか私は興味があります。

これにアプローチする方法は、あなたのグループの雰囲気によって異なります。それが非難の文化である場合、私は謝罪とあなたがそれをどうするかについて非常に慎重になるでしょう。協力的で前向きな雰囲気なら、「台無しになった、ごめんなさい。今後これを避けるにはどうすればいいの？」という言葉に沿ったものです。おそらく良い考えです。

いずれにせよ、このような間抜けには、a）それがどのように起こったのかを見つけ、b）それが再び起こる可能性を最小限に抑えるための何らかの事後分析を伴うべきです。

私はあなたの構造に精通していません（私は非常に異なる環境で働いています）が、最終的には、現実は時折、人々が間違いを犯し、物事が壊れるということです。経験から学び、先に進みます。

私の環境では、ビルドを壊した場合、あなたは良い性質のうねりと気の利いた彗星を得るでしょう。どの英語圏の国に住んでいるかはわかりませんが、英語を母国語としない人としては、コメントに下線を引く性質が得られない可能性があります。

シニア開発者として反対側から来た私は、あるコードレビューが、コードが悪かったからではなく、プロジェクトの構造に影響を与えたために「吸い込まれた」とコメントしたことがあります。構造的な問題を解決する必要があるのは、私自身のコメントです。後になって、私の不正確なフリッパーのスピーチのために彼に非常に怒っていたにもかかわらず、Jr Devを発見しました。

あの 壊れたビルドトークンを取得します。狂犬病を次の幸運な受取人に渡します。常に起こります。品質は重要ですが、間違いは避けられません。それらを修正します。進め。次の貧しい人々を恥じなさい。

一般的なルールとして、私は言うだろう：

チェックインによってコンパイラエラーが発生する場合は、チェックインする前に「最新版を取得する」ことで自分自身を捕まえたでしょう。単純な「おっと、私の悪い」が順番に並んでいます。（特に、翌朝10時に散歩し、誰がどのチェンジセットにロールバックするかを決定している場合）

チェックインが一般的な予期しない動作を引き起こした場合、ランタイムエラーが発生したとしても、それがあなたに対して行われるべきではないと思います。それは領土が付属しています。誰もが「最新版を入手」するのが一般的にコンパイラに合格している限り、人々は本当にデータベースを削除したり、プロジェクトのサーバーコピーを削除したり、すべての変更セットを削除したりするような例外を除いて、本当に当てはまるべきではありません人々が悪意を持たなければならないことは愚かです）。

TEAMは失敗しました。

あなたの会社は、最初のビルドを行う開発者に対してより多くのコードレビューが必要です。

チームがレビューを行い、あなたが物事を正しく行っている途中でいくつかの保証を提供することなく、これを続けることをチームが許可する方法がわかりません。

リリース時間に近いことは言い訳ではありませんが、新しいコードを再確認するより良い理由です。

リリースを簡単に取り消せない場合、このグループにはさらに大きな問題があります。

人々があなたの周りにいる理由がわかりません。システムがうまくセットアップされていれば、彼らはあなたの変更をいじったり、非常に迅速に修正できるはずです。

繰り返しますが、もしあなたがWindowsビルドを壊した人の一人なら、それから...仕方がありません。（誰もがMSビルドの哲学に疑問を呈する前に、それをやるのは信じられないほど難しいが、ときどき誰かがそれを行う-そして、会社全体のQAは1日停止する）。

そして、ええ-謝らないでください。上司とチャットをして、あなたがあなたがしたことから学んだことを彼に理解させてください。

ビルドは常に壊れます。バグと間違いは人生の事実であり、そのため、バグと間違いの影響を最小限に抑えるプロセスが必要です。

ビルドの破損がそれほど重大な場合は、プロセスが破損していることを意味します。

毎晩のビルドではなく、継続的なビルドを行う必要があります。

決して答えるよりも遅い答えの方が良い...

他の多くの人が言っているように、ビルドを壊したことを謝罪しないでください。それがあなたであることを認めて、仕事を続けてください。このようなことは、あなたがそこにいたかどうかに関係なく起こります。そして、だれもそれのために下手に扱われるに値する人はいません。人々はプレッシャーの下でひどく反応するので、落ち着いて仕事を続けることができれば、それが重要なときに目立ちます。人々があなたに苦労するときの私のアドバイスは、単に防御的であることを避け、あなたが問題に直面していることを人々に知らせることで状況を緩和することです。

個人的に、私は壊れたビルドを機会と考えています。

• ビルドが壊れて、それがあなたのせいであると証明できる場合、継続的な統合とビルドプロセスが仕事をしていることを示す可能性があります。プロセスを検証するため、これは良いことです。ビルドが壊れない場合、何か問題があったのではないかと心配します。
• かなり一般的な方法でビルドを壊し、この方法で頻繁に壊す場合、CIプロセスに何かが欠けている可能性があります。これは、一般的な障害シナリオをより適切に管理できるようにプロセスを改善する機会です。
• 任務を超えて、あいまいな問題で実際にビルドを台無しにした場合、チームの他のメンバーに警告を発するのに十分に重要であるかもしれない何か新しいことを学ぶ機会があります。

だから私が言っていることは、ビルドを時々壊すことは、人々が仕事をしていることを意味するということです。間違いを犯したかもしれませんが、学習の機会としてそれを使用する場合は、次回より良いことをすることを学習するだけで仕事をしています。

チェックインごとにCIビルドが必要であることを伝えます。そうすれば、夜間に壊れるのを知るまで待つ必要はありません。うん!!! 間違っているのはプロセスであり、他に何もないことを伝えます。システムのギャップを特定しました。

しかし、はい、それを修正してください。大したことではありません。本番ではありません。ただ価値のない毎晩。

私の会社での通常のプラクティスは次のとおりです。

• 「私じゃない！」と叫ぶ （それ以外の場合、通常はCVS / SVN証明）
• 「my-userlogin ist Schuld！」と言うTシャツを着ています。（はい、開発者自身のそのようなシャツの50％）
• ローカルsendboxで機能し、すべてのテストが正常に合格したと主張する

私の会社には、このような「インシデント」を処理する優れた方法もあります。

• 労働者は半日以下の衣装を着用しなければなりません（http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html）

• 謝りません。

• 壊れたビルドのコミットを許可したCIの責任者を非難します。

• 開発者が壊れたコードをコミットするのを防ぐために、CIプロセスを配置する必要があります。

• ローカルビルドが失敗した場合、ビルドサーバーに入ることは許可されません。

何らかの謝罪ができると思いますが、「これが二度と起こらないようにするつもりです」と言わないでください。するから。そして、もしそれがあなたを噛むでしょう。

オープンソースプロジェクトに取り組んでいる場合、

「申し訳ありませんが、ビルドを壊しました。眠すぎたかもしれません！」

githubのコメントとして追加します。

多くのオープンソース開発者が深夜にコードを書くためです。