同僚が自分のPCでテストする必要がないと考えると、彼は変更を加え、コミットしてからプッシュします。次に、彼は実稼働サーバーでテストを行い、ミスを犯したことに気付きます。週に1回発生します。現在、彼は3つのコミットを行い、5分以内に運用サーバーへの展開をプッシュしていることがわかります。

私は彼に、これは良い仕事がどのように行われるかではない、と何度か言った。私は彼に再び失礼になりたくありません、そして、彼は会社で私と同じ地位にあります、そして、彼はここで私より多くをしました。

この振る舞いを何らかの形で罰するか、できる限り不快にしたいのです。

始める前に、会社はFTPなどの旧式な方法を使用して展開していましたが、バージョン管理はありませんでした。

Git、Bitbucket、Dploy.io、およびHipChatを使用するように強制しました。展開は自動ではなく、誰かがdply.ioにログインして展開ボタンを押す必要があります。

さて、実稼働サーバーでテストしないように強制するにはどうすればよいですか？HipChatボットのようなものは、同じ行で繰り返し編集が行われていることを感知し、プログラマーに通知を送信できます。

適切な品質保証（QA）プロセスが必要です。

プロのソフトウェア開発チームでは、開発から本番にプッシュすることはありません。開発、ステージング、および本番の少なくとも3つの別々の環境があります。

開発環境で何かが機能していると思ったら、まずステージングにプッシュします。各コミットはQAチームによってテストされ、そのテストが成功した場合にのみ本番にプッシュされます。理想的には、開発、テスト、および実稼働へのプッシュは、別々の人が行います。これは、開発者が開発からステージングにのみ展開でき、QAチームがステージングから実稼働にのみ展開できるようにビルド自動化システムを構成することで保証できます。

QAを行うために誰かを雇うように経営陣を説得できない場合、おそらくあなたの一人が他の人のためにその役割を果たすことができます。私はdiploy.ioを使用したことはありませんが、一部のビルド自動化システムは、ユーザーが開発からステージングおよびステージングから本番への両方をデプロイできるように構成できますが、同じビルドに対して両方を行うことはできないため、2人目は常に必要です（ただし、あなたのいずれかが不在の場合は、バックアップ担当者がいることを確認してください）。

もう1つのオプションは、サポートスタッフにQAを行わせることです。これは、彼らにとっては追加の作業のように思えるかもしれませんが、長期的に作業を安全にすることができるアプリケーションへの変更を確実に認識できるようにします。

おそらく開発サーバー、できればステージング環境も取得したいと思うでしょう。自分の個人Webサイトを除き、誰もローカルから本番にプッシュするべきではありません。展開プロセスは、dev-> staging-> prodのみをサポートする必要があります。おそらく、新しいリリースの承認を担当する人が必要です-組織によっては、プロジェクトリーダー、専用のQA、または毎週交代する義務があります（具体的なリマインダーで、たとえばその週にふわふわのおもちゃを持っている人だけが押す）。ただし、最初にチームと話し合い、賛同を得ます（以下を参照）。

この振る舞いを何らかの形で罰するか、できる限り不快にしたいのです。

テストスイート（これらの1つをお持ちですか？）に、運用サーバーにいるかどうかを確認するチェックを含めることができます。その場合、オフィスの全員にを伝えるメールを送信しますLooks like $username is testing on prod, watch out。同僚を公然とsha辱することは、おそらく不快です。または、チームが製品をIPで禁止するなどの技術的な制限を作成することもできます（これは解除できますが、正当化する必要があります）。

ただし、prodでテストしている人ではなく、問題のように見え、気にしないチームの人々に非常に不人気になる可能性があります。

本当にあなたが本当に欲しいのは、この振る舞いを罰するのではなく、止めることです。

私はそれらを使用するように強制しました[...]

ワークフローの改善を提唱しているのはすばらしいことですが、同僚のことをあまり考えていないか、完全にサポートされていないようです。これにより、同僚がワークフローと半熱的にやり取りし、コードを本番環境に導入するために必要な最小限の作業を行い、ワークフローの精神に実際に従わない可能性が高くなります。そして、ワークフローとの不適切な相互作用の結果を明確化するためにますます多くの時間を費やしている場合（誰も気にしないからですよね？）、他の誰もがワークフロー自体に疑問を呈しています。

だから、会話から始めましょう。

なぜそれが起こっているのかを調べてください（同僚のマシンはテストに適していませんか？同僚は機能ブランチについて不確かであるか、コミットとプッシュが同じsvnマインドセットで立ち往生していますか？）、テストされていないコードが問題になる理由を説明してくださいdev / staging / prodで、なぜそれが起こるかを変更するために何かできるかどうかを確認します（単にあなたが彼らを非難した場合よりも、ローカルでテストしたほうが良い場合、同僚はあなたが望むことをする可能性が高くなります）。

それを解決できず、意見の相違に本当に帰着する場合は、次の回顧会議でチーム全体の議論をスケジュールし、同僚が何をしているか考えてください。主張するが、コンセンサスに耳を傾ける。たぶんあなたのチームは、テキストによる修正をローカルでテストしなくても良いと言っており、大きな機能がテストされていない状態で開発に適用されないというルールがあります。ミーティングに書き留めて、各環境で許可されていることについて集合的に決定した内容を読み上げます。数か月後に日付を設定し、おそらく回顧展でレビューします。

職場では、Gerritを使用してこれを回避しています。Gerritは、通常「マスター」と呼ばれるメイン/本番Gitブランチへのゲートとして機能するコードレビューシステムです。コードレビューがありますよね？あなたは個人的に例外的にそれらを行うように聞こえます。Gerritを使用すると、一種のステージングブランチにプッシュします。このブランチは、あなたと同僚がコードレビュープロセスを十分に実行した後、Gerritをmasterブランチにマージします。GerritをCIサーバーにフックして、変更を確認するためのメールを受け取る前に単体テストを実行することもできます。CIツールを設定できるサーバーがない場合、Codeshipには概念実証として使用するための便利な無料プランがあります。

最後に、もちろん、コードのレビューと単体テストを生き残った認可されたビルド製品からのみ、運用展開を自動化することです。このためにいくつかのクールな技術が登場しますが、それが炎の餌になるのではないかということについては言及しません。

ソリューションを使用して上司に連絡してください。これはあなたにも当てはまり、同僚を罰するだけでなく、全員のコード品質を改善する方法です。

これは主に人間の問題だと考えています。プロセスは存在し、ツールは存在しますが、プロセスは順守されていません。

ここで他の人が言ったことに同意します。問題の開発者がSVNの考え方にとらわれている可能性が非常に高い可能性について、そして彼はプロセスをフォローしていると考えるかもしれません。

この種の問題に対処する最良の方法は、特に明確な上司がいない場合、罰やアクセスの削除を中心にしないことです。プロセス（常に1つあり、私は以前に「あの人」だったことがあります）、あなたは最も熱をかける可能性が高い人です。最初にプロセスについて人々を同意させることを中心に展開します。

これは、本番環境での重大なインシデント後の「教訓」型の会議のような構造化された会議が非常に役立つ場所です。問題の開発者、コードレビュー、単体テスト、包括的なテストなどすべてを毎回行う必要があることを全員に同意してみてください（ステージング環境のアイデアをここから紹介できます）。それは難しくないはずであり、非常に賢明です。次に、チームに、どのように行うべきかについて、いくつかの堅実なルールを一緒に考え出すよう依頼します。問題の原因となっている開発者が貢献すればするほど、ルールを順守しているように感じるようになり、振る舞いが問題である理由を確認し始めます。

最後のポイントは、「まあ、以前よりも良くなった！」トラップ。常に改善の余地があります。私の経験では、IT業界の人々は、いくつかの改善を行った後、自分が持っているものに落ち着き始めるのが一般的です。その後、再び危機に直面するまで、落ち着きが続きます。

これは、特に小さなチームでは珍しいことではありません。それについて大したことはしないでください、しかし非公式なルールを作ります：

ビルドを壊し、ドーナツを持ち込みます。

1）週に2回ドーナツを受け取るか、2）規格に準拠します。

会議でそれを持ち出します。言うまでもなく、名前でだれにも言及しないでください。「バージョン管理と展開の標準を導入して以来、物事はずっと簡単になり、サーバーは以前よりもずっと稼働しています。これは素晴らしいです！ただし、適切なテストを行わずにショートカットを作成して送信するのは魅力的ですが、それはギャンブルであり、サーバーが稼働しています。サーバーを破壊するコードを送信した場合は、責任者が翌日にチームのためにドーナツ。」

必要に応じてドーナツを他のものに置き換えて、高価にしないでください-チーム全体の昼食は多すぎますが、ドーナツや果物/野菜トレイ、またはチップとディップなどの5ドルの箱はおそらく面倒ですチームや会社から彼らを遠ざけるような負担をかけることなく、テストをスキップすることの利便性に対して実際にリスクを比較検討するのに十分です。

さて、どうすればそれらを強制することができます...

同僚に無理矢理させるのではなく、同僚に自分の視点から物事を見せるようにしてください。これにより、すべての人にとって物事がずっと簡単になります。それは私を…に導く

この振る舞いを何らかの形で罰するか、できる限り不快にしたいのです。

ライブサーバーで問題が発生するのはなぜ苦痛なのでしょうか？彼が知らないことを知っていますか？彼があなたのやり方で物事を見るようにするために何ができますか？

あなたがこれで成功すれば、あなたは彼の中で最高を引き出し、彼はあなたが考えもしなかった問題の解決策を見つけるでしょう。

一般に、問題を理解できないプロセスに強制するのではなく、人々と協力して問題を解決するようにしてください。

起こりうる最悪のことは何ですか？古いバージョンを復元することでデータベース内のランダムなレコードを変更するバグを修正できるほど十分なバックアップがありますか？

レコードIDを使用するバグがあり、間違ってセントの請求額がレコードIDに使用される変数に保存されているとします。したがって、$ 12.34を支払うと、ID 1234のレコードが変更されます。バグが検出されるまでソフトウェアが数時間実行された場合、そこから回復できますか？（正しいレコードとレコード1234の両方が更新された場合、レコード1234が使用されている場合にのみこれを検出するため、これはかなり長い間検出されない可能性があります）。

今、あなたの非常にやる気のある開発者に彼がこれについてどう思うか尋ねてください。過去にそうしてきたため、間違いを犯さないと主張することはできません。

考えられるさまざまなプロセスおよび技術的ソリューションを明確に理解している。問題は同僚の管理方法です。

これは基本的に変更管理の演習です。

第一に、あなたの視点で彼/彼女が参加していることを確認するために、私は創設者と静かな言葉を持っています。生産の停止があった場合、創業者はそれについて非常に懸念し、変化を望んでいると予想されます。

第二に、あなたは小さなチームで働いており、チーム全体をプロセス改善に従事させることは価値があります。

定期的な（たとえば毎週）プロセスの回顧を設定します。チーム全員に：

• 問題を特定する
• 労働慣行を改善するためのボランティアのアイデア
• それらの慣行の実施に従事する

当然のことながら、チーム全体が改善されたプラクティスのコンプライアンスを確保することも支援します。

あなたはいくつかの問題を特定したと思います：

1. チェックインするコードは、コードをチェックインする権限を持っている人なら誰でも簡単に本番環境にプッシュできるようです。

率直に言って、私はそのセットアップが非常識だと思います。最低でも、手動での生産へのプッシュをトリガすることができます人々は信頼できる人々のセットに制限する必要があり、完全に徹底的に見直し、プッシュをトリガする前に（関係なく、変更を執筆している人の）すべての発信変更をテストします。コードをチェックインする権限を持つ人に、本番へのプッシュを任意にトリガーする権限を与えることは、単にトラブルを求めているだけです。不注意な開発者や無能な開発者からだけでなく、不満を抱いている開発者やアカウントの1つを侵害する悪意のある第三者からも。

また、プッシュボタンプロセスを使用して、チェックインされるすべての変更を展開する場合、自動テストの包括的なスイートを用意する必要があり、ボタンを押すとそれらを実行する必要があります（そして、展開を中止する場合テストはすべて失敗します！）。プロセスは、表面的にテストされていないコードであっても、そもそも運用システムに展開されるポイントに到達することを許可すべきではありません。

同僚は、最初にテストせずにコードをチェックインするという点で大きな間違いを犯しました。あなたの組織は、あらゆる状況下でテストされていないコードが本番環境に到達することを可能にする展開プロセスを採用することにより、はるかに大きな間違いを犯しています。

したがって、ビジネスの最初の順序は、展開プロセスを修正することです。実稼働へのプッシュをトリガーできるユーザーを制限するか、自動展開プロセスに妥当な量のテストを組み込むか、またはその両方を行います。

2. 明確に定義された開発標準/原則を設定していないようです。

特に、「完了」の明確な定義が欠落している、および/または「コードがテストされた」を含まない定義を使用して、コードをチェックイン/プロダクションにデプロイする際のゲーティング要素として使用しているようです。これがある場合、「良いコードはこのように生成されない」と単に指摘する代わりに、「このコードは、私たち全員が合意した最低限の基準を満たしていないため、未来"。

開発者に期待されることと、開発者が維持することを意図している標準とレベルを明確に伝える文化を確立するよう努めるべきです。少なくとも手動テスト（または、できれば、ビルド/デプロイプロセスの一部として実行できる自動化されたテストケース）を含むdoneの定義をセットアップすることは、それを支援します。ビルドを壊す結果をもたらす可能性があるように。または、生産システムを破壊するためのより深刻な結果。これら2つのことは実際には独立している必要があり、ビルドと実動システムの両方を同時に壊すことは完全に不可能であることを注意してください（壊れたビルドはデプロイ可能でないため）。

会社に継続的インテグレーション+ピアレビュープロセスを統合する必要があります。Bitbucketはそれを簡単にします。

そして、他のユーザーによって提案された開発サーバーへの+1。

彼を失礼にしないでください、それはあなたの仕事上の関係を損なうだけです。