同僚がテストせずにコミットしてプッシュする
私の同僚が自分のPCでのテストは必要ないと考えたとき、彼は変更を加えてコミットしてからプッシュします。次に、本番サーバーでテストし、間違いを犯したことに気付きました。週に1回発生します。これで、彼は3つのコミットを行い、5分以内に本番サーバーへのデプロイメントをプッシュしたことがわかります。
これは、良い仕事をする方法ではないことを何度か彼に話しました。私は彼に失礼な態度をとりたくありません。彼は会社で私と同じ地位にあり、彼はここで私よりも多く働いています。
私はこの行動を何らかの方法で罰せたり、できるだけ不愉快にさせたりしたいと思っています。
私が始める前は、FTPなどの旧式の方法を使用して会社が展開しており、バージョン管理はありませんでした。
私は彼らにGit、Bitbucket、Dploy.io、HipChatの使用を強制しました。展開は自動ではなく、誰かがdply.ioにログインして展開ボタンを押す必要があります。
さて、どうすれば本番サーバーでテストしないように強制できますか？ HipChatボットのようなものは、同じ行で編集が繰り返されていることを感知して、プログラマーに通知を送信できます。
適切な品質保証（QA）プロセスが必要です。
プロのソフトウェア開発チームでは、開発から本番にプッシュする必要はありません。少なくとも3つの別々の環境があります。開発、ステージング、本番です。
開発環境で何かがうまくいったと思ったら、まずステージングにプッシュします。各コミットはQAチームによってテストされ、そのテストが成功した場合にのみ、本番環境にプッシュされます。理想的には、開発、テスト、本番へのプッシュは別々の人が行う必要があります。これは、開発者が開発からステージングにのみデプロイでき、QAチームがステージングから本番にのみデプロイできるようにビルド自動化システムを構成することで保証できます。
QAを行うために誰かを雇うよう経営陣を説得することができない場合、おそらくあなたの1人が他の人のためにその役割を果たすことができます。私はdiploy.ioを使用したことはありませんが、一部のビルド自動化システムは、ユーザーが開発からステージング、ステージングから本番までの両方をデプロイできるように構成できますが、同じビルドで両方を実行できないため、2人目は常に必要です（ただし、あなたの1人が不在のときのために、バックアップ担当者を何人か用意してください）.
別のオプションは、サポートスタッフにQAを依頼することです。これは彼らにとっては追加の作業のように見えるかもしれませんが、長期的に見れば一部の作業を保護できるアプリケーションの変更を確実に認識できるようになります。
おそらく、開発サーバー、そしてできればステージング環境も取得したいと思うでしょう。自分の個人的なWebサイトを除いて、誰もローカルから本番環境に移行するべきではありません。デプロイプロセスは、dev-> staging-> prodのみをサポートする必要があります。おそらく、新しいリリースの承認を担当する人が必要でしょう-組織によっては、これはプロジェクトリード、専用QA、または毎週ローテーションする義務（具体的なリマインダーで、たとえば、その週にふわふわのおもちゃを持っている人のみが押す）。ただし、最初にチームと話し合って、賛同を得てください（以下を参照）。
私はこの行動を何らかの方法で罰せたり、できるだけ不愉快にさせたりしたいと思っています。
テストスイート（それらの1つを持っていますよね？）に、運用サーバーにいるかどうかを確認するチェックを含めることができます。そうであれば、オフィスの全員にLooks like $username is testing on prod, watch out。おそらく、同僚を公に恥ずかしく思うのは不快でしょう。または、チームが製品を見るのをIP禁止するなどの技術的な制限を作成することもできます（これは解除できますが、正当化する必要があります）。
しかし、私はそれをお勧めしません、あなたは問題のように見え、製品でテストしている人ではなく、気にしていないチームの人々に非常に不人気になる可能性があります。
確かにあなたが本当に望んでいるのは、この振る舞いが罰せられるのではなく、stopになることですか？
私は彼ら/私たちに使用を強制しました[...]
ワークフローの改善を提唱しているのは素晴らしいことですが、同僚のことをあまり考えていないか、完全なサポートを得られていないようです。これにより、同僚がワークフローと熱く相互作用し、コードを本番環境に移行するために必要な最小限の作業を行い、ワークフローの精神に実際には従わない可能性があります。つまり、片付けに費やす時間が増えることになります。そして、ワークフローとの不適切な相互作用の結果を片付けるためにますます多くの時間を費やしているとき（他の誰も気にしないので？）、他の誰もがワークフロー自体に疑問を投げかけるでしょう。
会話から始めましょう。
なぜそれが起こっているのかを調べてください（同僚のマシンはテストに向いていませんか？同僚は機能ブランチに不確かですか、コミットとプッシュが同じであるsvnの考え方に行き詰まっていますか？）、テストされていないコードが問題になる理由を説明してくださいdev/staging/prodで、なぜそれが発生するのかを変更するために何かできるかどうかを確認します（単に同僚を怒らせただけの場合よりも、ローカルでテストしたほうがいい場合は、同僚が望むことを行う可能性が高くなります）。
それを解決することができず、それが本当に意見の相違に帰着する場合は、次回の回顧会議でチーム全体の議論をスケジュールし、同僚が何をしているかを考えてください。あなたの主張をしなさい、しかしコンセンサスに耳を傾けなさい。多分あなたのチームはテキストによる修正をローカルでテストしないことは大丈夫だと言っています、そしてあなたはテストされていない大きな機能が開発に進まないというルールを持っているだけです。会議に書き留め、各環境で何が許可されているかについて集合的に決定した内容を読み上げます。おそらく過去を振り返って、数か月後に日付を設定して確認してください。
仕事では Gerrit を使用してこれを回避します。 Gerritは、通常「マスター」と呼ばれているメイン/本番Gitブランチへのゲートとして機能するコードレビューシステムです。コードレビューがありますよね？あなたは個人的に例外的にそれらを行うように聞こえます。 Gerritを使用すると、一種のステージングブランチにプッシュします。このブランチは、あなたと同僚がコードレビュープロセスを問題なく実行した後、Gerritがマスターブランチにマージします。 GerritをCIサーバーにフックして、誰かが変更をレビューするための電子メールを受け取る前に単体テストを実行することもできます。サーバーがない場合は、CIツールを設定できます。 Codeship には、概念実証として使用できる素晴らしい無料プランがあります。
もちろん、最後に、コードのレビューと単体テストに合格した認定ビルド製品からのみ、本番デプロイメントを自動化します。これにはいくつかクールなテクノロジーが登場しますが、炎の餌になるのではないかと心配しておきます。
解決策を上司に伝えてください。これはあなたにも当てはまり、同僚を罰するだけでなく、全員のコード品質を向上させる方法です。
私はこれを主に人間の問題と見なしています-プロセスはそこにあり、ツールはそこにありますが、プロセスは単に守られていません。
問題の開発者が [〜＃〜] svn [〜＃〜] マインドセットで立ち往生している可能性について、他の人がここで言ったことに同意します。彼はプロセスに従います。
私はこの種の問題に対処する最良の方法、特に明確な上司がいない可能性がある場合は、罰やアクセスの削除を中心に考えていません。プロセス（常に1つあり、私は以前に「あの人」でした）、あなたは最も熱を奪う可能性が高い人です。それは、人々が最初にプロセスについて合意することを中心に展開します。
これは、本番環境での重大なインシデントの後の「教訓」型の会議などの構造化された会議が非常に役立つ場合がある場所です。問題の開発者を含む全員に、コードレビュー、単体テスト、包括的なテストなどすべてを毎回行う必要があることに同意してもらいます（ここでステージング環境のアイデアを導入することもできます）。それは難しいことではなく、非常に賢明です。次に、どのようにすべきかについてしっかりしたルールを一緒に考え出すようチームに依頼します。問題を引き起こしている開発者が貢献すればするほど、彼らはルールを守りたくなり、なぜ彼らの振る舞いが問題であったのかを理解し始めます。
最後のポイントは、「まあ、それは以前よりも優れている」に陥ることは決してないということです。トラップ。常に改善の余地があります。私の経験では、IT業界の人々は、いくつかの改善の後に、彼らが得たものに落ち着くのが一般的です。その後、再び突然危機的な状況に陥るまで、解決は続きます。
これは珍しいことではありません 、特に小さなチームでは。それについて大したことはしませんが、非公式のルールを作ってください：
ビルドを壊して、ドーナツを持ってきてください。
1）週に2回ドーナツを受け取るか、2）標準に準拠します。
会議で取り上げてください。非難せずに、名前で誰かに言及しないでください。ただし、次のようなものです "バージョン管理と導入の標準を導入したため、状況がはるかに簡単になり、サーバーの稼働時間が長くなりました。これは素晴らしいことです！しかし、適切なテストを行わずにショートカットを実行して送信することは依然として魅力的です。しかし、それはギャンブルであり、サーバーは待機中です。今後、私たちのいずれかがサーバーを壊し、担当者は翌日チームにドーナツを持ち込みます。」
必要に応じてドーナツを別のものに置き換えて、高価にしないでください-チーム全体の昼食は多すぎますが、5ドルのドーナツや果物/野菜のトレイ、チップやディップなどはおそらく迷惑でしょう。チームや会社から離れる負担をかけずに、テストをスキップすることの利便性と実際にリスクを比較検討するのに十分です。
では、どうすればそれらを強制できますか...
同僚に強制するのではなく、自分の視点から物事を見せるようにします。これは誰にとっても物事をはるかに容易にします。それが私を…に導きます.
私はこの行動を何らかの方法で罰せたり、できるだけ不愉快にさせたりしたいと思っています。
ライブサーバーの問題であなたにとって苦痛なのはなぜですか？彼が知らないことを知っていますか？彼にあなたのやり方で物事を見せるためにあなたは何ができますか？
あなたがこれで成功した場合、あなたは彼の中で最高のものを引き出し、彼はあなたが考えたことのない問題の解決策を見つけるでしょう。
一般に、理解できないプロセスに強制するのではなく、人と協力して問題を解決しようとします。
起こり得る最悪は何ですか？古いバージョンを復元することでデータベースのランダムなレコードを変更するバグを修正できるのに十分なバックアップがありますか？
レコードIDを使用するバグがあり、誤って請求書の金額（セント単位）がレコードIDに使用される変数に格納されているとします。したがって、12.34ドルを支払うと、ID 1234のレコードが変更されます。バグが検出されるまで数時間ソフトウェアを実行すると、そこから回復できますか？ （正しいレコードとレコード1234の両方が更新された場合、これはレコード1234が使用されている場合にのみ検出されるため、しばらく検出されない可能性があります）。
次に、意欲的な開発者に、これについてどう思うか尋ねてください。明らかに、過去に犯したことがあるので、間違いを犯したことはないと主張することはできません。
考えられるさまざまなプロセスと技術ソリューションを明確に理解している。問題は、同僚の管理方法です。
これは本質的に変更管理の練習です。
まず、創設者があなたの視点に沿っていることを確認するために、静かなWordを用意します。生産停止があった場合、創業者はそれを非常に気にかけて変化を望んでいると思います。
第二に、あなたは小さなチームで働いており、チーム全体がプロセス改善に従事するように試みることはおそらく価値があるでしょう。
定期的（たとえば、毎週）のプロセスを振り返って設定します。チーム全員がいる：
- 問題を特定する
- 労働慣行を改善するためのボランティアのアイデア
- これらのプラクティスの実装に従事する
当然のことながら、チーム全体が改善されたプラクティスへのコンプライアンスを確実にするのにも役立ちます。
私はあなたがいくつかの問題を識別したと思います：
- チェックされたコードは、コードをチェックインする権限を持つ人なら誰でも簡単に本番環境にプッシュできるようです。
率直に言って、私はそのセットアップは非常識だと思います。少なくとも、本番へのプッシュを手動でトリガーできるユーザーは、すべてを徹底的に確認およびテストするために信頼できる完全に信頼できるユーザーのセットに制限する必要がありますプッシュをトリガーする前のアウトバウンド変更（誰が変更を作成したかに関係なく）。コードをチェックインする権限を持っている人に、プロダクションへのプッシュを任意にトリガーする権限を与えることは、問題を求めているだけです。不注意な、または無能な開発者だけでなく、不満を抱いている開発者や、アカウントの1つを侵害している悪意のあるサードパーティからもです。
また、プッシュボタンプロセスを使用して、チェックインされたすべての変更をデプロイする場合は、自動テストの包括的なスイートを用意し、ボタンを押すとそれらを実行する必要があります（そして、すべてのテストが失敗します！）。プロセスでは、表面的にテストされていないコードでも、そもそも本番システムにデプロイされるところまで到達してはなりません。
最初にテストせずにコードをチェックインするという点で、同僚が大きな間違いを犯しました。組織は、テストされていないコードがどのような状況でも本番環境に到達できるようにするデプロイメントプロセスを採用することにより、はるかに大きな間違いを引き起こしています。
したがって、最初の業務は、展開プロセスを修正することです。本番へのプッシュをトリガーできるユーザーを制限するか、自動デプロイメントプロセスに妥当な量のテストを組み込むか、またはその両方を行います。
- 明確に定義された開発標準/原則を設定していないようです。
特に、明確な " definition of done "がないか、コードをチェックする際のゲーティングファクターとして "コードがテストされました"を含まないものを使用しているようです/コードを本番環境にデプロイします。これがあった場合、「良いコードはこのように作成されていない」と指摘するだけでなく、「このコードは、私たち全員が合意した最低基準を満たしていません。未来"。
開発者に何が期待されているか、彼らが守ろうとしている標準と品質のレベルを明確に伝える文化を確立するように努めるべきです。少なくとも手動テスト（または、できれば、ビルド/デプロイプロセスの一部として実行できる自動テストケース）を含む、doneの定義を設定すると、それが役立ちます。ビルドを壊す結果をもたらすことができるように。または、生産システムを破壊することによるより深刻な結果。これら2つは実際には独立している必要があり、ビルドと本番システムの両方を同時に破壊することは完全に不可能であるべきであることに注意してください（破壊されたビルドは決してデプロイできないはずです）。
継続的インテグレーション+ピアレビュープロセスを会社に統合する必要があります。 Bitbucketはそれを簡単にします。
そして、他のユーザーによって提案された開発サーバーに+1します。
彼に失礼な態度をとらないでください、それはあなたの仕事の関係を傷つけるだけです。