ビルドがほとんど常に壊れているときに効率を維持する方法

私は同じソースコードを共有し、継続的に統合されている中規模のチームで働いていますが、私たち全員が同じブランチで作業しなければならないため、ビルドはほとんど常に壊れています。

また、壊れたビルドを軽減するために最近導入されたルールもあります。これは、ビルド中は誰もチェックインできないことを示しています。

そうは言っても、1日の間に誰もがチェックインできる10〜15分のウィンドウを持っています。

チームが成長するにつれて、チェックインの機会の窓はさらに小さくなります。そのため、開発者は変更をローカルに蓄積する必要があり、その結果、変更セットが大きくなり、変更が何も破壊しないことを保証するのがさらに難しくなります。悪循環を見ることができます。

このような環境で私が効果的に仕事を続けられるようにするために何をお勧めできますか。また、私はマネージャーではなく開発者であり、プロセスや他の人の行動をあまり変更できないことに注意してください。

まず、このコメント：

...ブランチを持つということは、余分な複雑さ、つまり余分な作業を意味します...

完全に偽です。分岐に慣れていない人からよく耳にしますが、まだ間違っています。

多くの開発者がローカルに変更を蓄積している場合、ローカルの変更はメインリポジトリの事実上のブランチを構成します。

彼らが最終的にプッシュするとき、これは事実上のマージです。

ブランチとマージが暗黙的であるという事実は、あなたが心配している余分な複雑さを取り除くものではなく、単に隠すだけです。真実は、このプロセスを明示的にすると、複数（チーム全体）がそれを管理するのに役立つ可能性があるということです。

さて、あなたは言う

ビルド中はチェックインできません

ただし、この場合、ビルドを修正することはできないため、正確性を高めることはできません。

一般に、ローカルでビルドするのが合理的である場合（つまり、ビルドが大きすぎたり遅くなかったりする場合）、開発者はプッシュする前にそれを行う必要があります。

そもそもそうではないと思います。なぜなら、そもそも壊れたビルドをプッシュしないからです。しかし、この点を明確にできれば素晴らしいと思います。

一般的には

ビルドがほとんど常に壊れているときに効率を維持する方法

です：ストップは、ビルドを壊します。

開発者...変更をローカルに蓄積します...悪循環を見ることができます。

それは実に悪質です。変更をローカルに蓄積することは、開発プロセスで何かがひどく腐敗していることを示す大きな赤い旗です。バージョンコントロールシステムを持つという全体の目的を破壊します。

プロセスや他の人の行動の変更を避けたい限り、最も自然な解決策は、独自のブランチを設定し、それを使用して変更を「蓄積」することです（チャンス）。

実際、あなたのような人がもっといる場合は、共同開発ブランチを共同で確立して、無能な管理アイデアに干渉されることなく、自由に更新を交換することもできます。分岐により、チームワークを簡素化するさまざまな方法が可能になります。

• ^{サイドノート、マネージャーがコミットを避けたり、コードをローカルに保持したり、その言葉を太字で平易な「私は無能だ」と訳したりするたびに。}

私はマネージャーではなく開発者であり、プロセスや他の人の行動をあまり変更できないことに注意してください...

精度のために、あなたが実際にすることができます（のようなもののためにウェブを検索、これらは影響力とコミュニケーション能力の問題であり、一つは本当に自分の好みに合わせて変更する事への電源の位置である必要はありません「まで管理」あなたならば'詳細に興味があります）。

しかしのはかなり面倒と労力がかかり、1は簡単です。滞在することを好む場合、私は完全に理解できる政治にはほとんど関与して、コーディングに焦点を当てて-そう、あなたがいない場合したい（あなたは理論的にもかかわらずことができます）、それは理解しやすいです。:)

私はあなたが環境を変えるのに無力だと感じるという考えに敏感ですが、この状況はプログラマーとしてのあなたのプロ意識に対する深刻な挑戦だと思います。

外科医が汚れたメスを清潔なメスと一緒に保管したらどうなりますか？配管工が取り付けたパイプをテストしなかった場合はどうなりますか？バイオリニストが常にオーケストラと調子が合わない場合はどうなりますか？

プログラマーがチームワークと一般的な礼儀を免除されるのはなぜですか？そのチームのメンバーとして、結果に対する責任を共有します。チームが自身の努力を妨害するため、チームを無視することは無責任です。

「ビルド中に誰もチェックインを許可しない」というルールがどこから来るのか興味があります。それがビルドを修正することに全員を集中させるなら、それは良いルールです。例を挙げてリードし、ビルドが壊れたときはいつでも修正できるようにします。それに直面しましょう、とにかく他のことは何もしていません。もしこれがあなたを困らせるなら、それらの懸念を表明することをお勧めします。積極的に状況を改善しようとしている人の声は、隅で不平を言う人よりも影響力があります。

あなたが「単なる開発者」であり、したがって、この問題に苦しむことになるものを変えることができないと思う限り、私は思う。

あなたがする必要があるのは、誰かがビルドを壊すたびにリポジトリからのすべてのコミットを元に戻し、その人にビルドを壊しただけで停止する必要があることを伝えることです。また、マネージャーにこの状況を説明し、この問題が原因でチームの生産性が低下していることを伝える必要があります。

プロセスをより良く変更するために、できる限りのことをする必要があります。むしろ、許可を求めるのではなく、後で申し訳なく言う。

あなたとあなたのチームは、プロセスを変更する必要があり、その壊れたモデルで効率的に作業できない状況にあると思います。また、問題を認識したときにその問題について何かをするのはあなたの責任だと思います。他に誰も問題について何もしなければ、あなたがしなければならない人です！

私はあなたの苦境に関連することができます、私は仕事で私の最新のプロジェクトで同様の状況に直面しました。私たちは、並べ替え、それがされるまで、最近のビルドを壊した開発者が子守/乳母/それを監視しなければならなかった「ホットポテト」システムの実装終わった固定 と渡されたすべての私たちの検証テストのを。

ビルドと検証のテストには通常約4時間かかったため、これは成功しました。ビルドを中断すると、実際の作業で半日を失うことになります。言うまでもなく、これにより、開発者はブランチをトランクにマージする前により効率的にブランチを使用するようになりました。ほとんどの開発者にとって、以前の考え方は「コードが壊れている場合、CIビルドシステムに通知するだけです」でした。

CIシステムに簡単な変更を加えるだけで、ビルドを中断する変更は自動的にロールバックされます。さらに良いことに、CIリポジトリをステージング領域にして、ビルドがグリーンの場合にのみ変更が権限のあるリポジトリにプッシュされるようにします。Gerritのようなツールがここで役立ちます。

ここで他の2つのことが役立ちます。

• チームはCIビルドをローカルでスモークテストできますか？ビルドを壊さないことを確認した場合、または少なくとも管理およびチームの怒りをコミットしてトリガーすることなく、一般的な方法でビルドを壊さないでください。
• CIの設計方法に応じて、破損したビルドを定義する方法は多数あります。これには、壊れたものの定義が含まれます-重い開発では、テストの失敗は壊れたものではなく、取り組むべき別の目標です。

しかし、あなたは本当に枝を見るべきです。