ビルドがほとんど常に壊れているときに効率を維持する方法
私は同じソースコードを共有する中規模のチームで働いており、継続的な統合を行っていますが、全員が同じブランチで作業する必要があるため、ビルドはほとんど常に壊れています。
壊れたビルドを緩和するために最近導入されたルールもあるので、ビルド中は誰もチェックインできないようになっています。
とはいえ、日中は全員がチェックインを許可した10〜15分のウィンドウがあります。
そして、チームが成長するにつれて、チェックインの機会の窓口はさらに縮小します。これにより、開発者は変更をローカルに蓄積する必要があり、その結果、変更セットが大きくなり、変更によって何も破壊されないようにすることがさらに困難になります。あなたは悪循環を見ることができます。
このような環境で効果的な作業を続けるために何をすすめますか。また、私はマネージャではなく開発者であり、プロセスや他の人の行動をあまり変更できないことに注意してください。
まず、このコメント：
...ブランチがあると、複雑さが増し、作業が増えることになります...
完全に偽です。分岐に慣れていない人からもよく耳にしますが、それでも間違いです。
多くの開発者が変更をローカルに蓄積している場合、そのローカルの変更はメインリポジトリのデファクトブランチを構成します。
彼らが最後にプッシュしたとき、これは事実上のマージです。
ブランチとマージが暗黙的であるという事実は、あなたが心配している余分な複雑さを取り除かず、単にそれを隠すだけです。真実は、このプロセスを明示的にすることは、あなた（複数の=チーム全体）がそれを管理することを学ぶのを助けるかもしれないということです。
今、あなたは言う
ビルド中は誰もチェックインできません。
ただし、この場合、ビルドを修正することはできないため、正確ではありません。
一般に、ローカルでビルドすることが妥当である場合（つまり、ビルドがtoo大きくないか遅い）でない場合、開発者はプッシュする前にそれを行う必要があります。
最初はそもそも壊れたビルドをプッシュしないので、そうではないと思いますが、この点を明確にしていただければすばらしいと思います。
一般に答えは
ビルドがほとんど常に壊れている場合に効率を維持する方法
is：ビルドの中断を中止。
開発者...変更をローカルに蓄積...悪循環を見ることができます。
本当に悪質です。変更をローカルに蓄積することは、開発プロセスで何かがひどく腐っていることを示す大きな赤い旗です。 バージョン管理システム を使用することの目的全体を破壊します。
プロセスや他の人の行動の変更を避けたい限り、最も自然な解決策は、独自のブランチをセットアップし、それを使用して変更を「蓄積」することです（取得したときにチームブランチとさらに統合される）機会）。
実際、あなたのような人が他にいる場合は、協力して共有開発ブランチを確立し、無能な管理のアイデアに干渉されることなく更新を自由に交換できます。 分岐 は、チームワークを簡素化するためのさまざまな方法を可能にします。
- 付記、そのマネージャーがコミットを回避するように強制する何かをするたびに、コードをローカルに維持し、彼らの言葉を太字でプレーンに翻訳します「私は無能です」。
私はマネージャではなく開発者であり、プロセスや他の人の行動をあまり変更できないことに注意してください...
正確さのために、あなたは実際にできます、これらは影響力とコミュニケーションスキルの問題であり、物事を好みに変更する力の位置にいる必要はありません（詳細については、 "manage up"などをウェブで検索してください）。
しかし、それはかなり面倒で手間がかかり、政治にほとんど関与せずに、コーディングに集中することを好むのであれば、完全に理解できます。したがって、want（理論的にはあなたできます）、それは理解できます。 :)
私はあなたが環境を変える力がないと感じているという考えに敏感ですが、この状況はプログラマーとしてのあなたのプロ意識にとって深刻な挑戦だと思います。
外科医が汚れたメスを清潔なメスと一緒に保管するとどうなりますか？配管工が彼が設置したパイプをテストしなかった場合はどうなりますか？バイオリニストが常にオーケストラと調律外で演奏した場合はどうなりますか？
プログラマーがチームワークや礼儀を免除されるべきなのはなぜですか？そのチームのメンバーとして、結果に対する責任を共有します。チームが自分の努力を妨害するので、チームを無視するのは無責任です。
「ビルド中にチェックインすることは誰にも許可されていない」というルールがどこから来ているのか知りたいのですが？それがビルドの修正に全員を集中させるなら、それは良いルールです。私は例を挙げてリードし、壊れたときはいつでもビルドを修正できるようにします。それに直面しよう、あなたはとにかく他に何もしていません。これがあなたを困らせるなら、私はそれらの懸念を表明することを勧めます。積極的に状況を改善しようとしている人の声は、隅で不平を言う人よりも影響力があります。
あなたがあなたが「単なる開発者」であると考える限り、この問題に苦しむことになるものを変えることはできないと思います。
あなたがする必要があるのは、誰かがビルドを壊すたびにリポジトリからすべてのコミットを元に戻し、その人にビルドを壊しただけで停止する必要があることを伝える必要があるということです。また、この状況をマネージャーに説明し、この問題のためにチームの生産性が低下していることをマネージャーに伝える必要があります。
あなたはプロセスをより良く変更するためにあなたができることは何でもする必要があり、むしろあなたは許可を求めるのではなく後で申し訳ないと言っています。
あなたとあなたのチームは、プロセス（必要）を変更する必要があり、その壊れたモデルで効率的に作業できない状況にあると思います。私はまた、あなたがそれを認識したときにその問題について何かをするのはあなたの責任だと思います。他の誰も問題について何もしない場合は、あなたがしなければならないのはあなたです！
私はあなたの窮状に関連することができます、私は仕事で私の最新のプロジェクトで同様の状況に直面しました。最終的にビルドを壊した開発者が、それがfixed[になるまで、それをbabysit/nanny/monitorしなければならなかった、一種の「ホットポテト」システムを実装することになりました。 〜＃〜] and [〜＃〜]合格all検証テストの合格。
ビルドと検証テストは通常4時間ほどかかったため、これは成功しました。ビルドを中断すると、実際の作業で半日を失うことになります。言うまでもなく、これにより、開発者はブランチをトランクにマージする前にブランチをより効率的に使用できるようになりました。ほとんどの開発者にとって、以前の考え方は、「コードが壊れた場合は、CIビルドシステムに通知させるだけです」でした。
CIシステムに簡単な変更を加えるだけで、ビルドが中断された変更は自動的にロールバックされます。さらに良いのは、CIリポジトリをステージング領域にして、ビルドが正常な場合にのみ変更が信頼できるリポジトリにプッシュされるようにすることです。ここではGerritのようなツールが役立ちます。
他に次の2つのことが役立ちます。
- あなたのチームはCIビルドをローカルで喫煙テストできますか？ビルドを中断しないことを確認した場合、または少なくとも管理とチームの怒りをコミットしてトリガーする必要がない限り、一般的な方法でビルドを中断しないでください。
- cIの設計方法に応じて、壊れたビルドを定義する多くの方法があります。これには、壊れたものを定義することが含まれます-激しい開発では、失敗したテストは壊れたものではなく、別の目標として取り組むことを検討します。
しかし、本当に枝を見る必要があります。