「継続的な」配信を実現するためのヒント

チームが頻繁にソフトウェアをリリースするのが困難になっています（毎週1回）。以下は、典型的なリリースのタイムラインです。

反復中：

• 開発者は、マスターブランチに基づいて、短期間（これは熱狂的に実施されます）機能ブランチのバックログのストーリーに取り組みます。
• 開発者は、頻繁に機能ブランチを統合ブランチにプルします。統合ブランチは、自動的に継続的に構築およびテストされます（テストカバレッジの範囲内）。
• テスターは、統合をステージング環境に自動展開する機能を備えており、これは週に複数回行われ、テストスイートの継続的な実行が可能になります。

毎週月曜日：

• （テスターの作業に基づいて）どのストーリーが「既知の善」であり、したがってリリースに含まれるかを決定するリリース計画ミーティングがあります。ストーリーに既知の問題がある場合、ソースブランチは統合から除外されます。
• テスターがリリースをカットするための安定したコードベースを確保するために、今週の月曜日に新しいコード（テスターに​​よって要求されたバグ修正のみ）を統合に取り込むことはできません。

毎週火曜日：

• テスターは、可能な限り時間をかけて可能な限り統合ブランチをテストし、既知のバグがないため、リリースがカットされ、運用ノードにゆっくりとプッシュされました。

これは実際には問題ないように思えますが、達成するのは非常に難しいことがわかりました。チームには次の症状が見られます

• 本番環境では、ステージング環境で特定されなかった「微妙な」バグが見つかります。
• 土壇場でのホットフィックスは火曜日まで続きます。
• 実稼働環境の問題にはロールバックが必要であり、ライブデプロイメントが成功し、マスターブランチが更新される（したがって分岐する）まで、継続的な開発をブロックします。

ここでは、テストの範囲、コードの品質、回帰テストの迅速な機能、土壇場での変更、環境の違いが関係していると思います。誰もが「継続的な」配信を達成するための最善の方法に関するアドバイスを提供できますか？

• ステージング環境では特定されなかった「微妙な」バグが本番環境で見つかりました。このような問題を抱えているプロジェクトの1つで、これは二重問題と呼ばれる戦術によって非常にうまく対処されました。そのようなバグについては、問題トラッカーで2つのチケットを作成しました：1つは開発者に割り当てられてコードを修正し、もう1つはテスターに​​割り当てられて回帰テストまたはステージング環境の変更を設計および確立します。これにより、演出するのに十分なステージングを維持できました。

• 実稼働環境の問題にはロールバックが必要です -これらが頻繁に発生する場合、毎週のリリースは実際には偽物です。実際に機能するレベルに頻度を調整することを検討してください。偽のすべてのことのカウントではなく、あなたが展開した回数である-私は2つの毎週のリリースのロールバックの発言の1つが、それは、ユーザーが新しい（作業）リリース2週間で一度に直面することを意味していることを意味します。

• 熱心に機能ブランチを実施しました -それはしばらく前に、あなたも単一のブランチで作業を試みて、それが劣っていることを意味したのですか？はいの場合、残りをスキップします。それ以外の場合は、単一のブランチで作業してみてください（必要に応じて、グーグルでブランチ戦略「開発ブランチ」またはブランチ戦略「不安定なトランク」の詳細を確認してください）。または、Perforceを使用している場合は、分岐とマージに関するMicrosoftのガイドラインをWebで検索してください。言ってみた？申し訳ありませんが、適切な言葉をテストする必要があります。つまり、1）現在のブランチよりも優れているかどうかをいつどのように測定するかを計画します。テストは失敗します。

PS。

おそらく、ソフトウェアプロジェクトのリスク管理のようなものをウェブで検索することで、そのようなトリックを見つけることができます。

更新

<コメントからコピー>

頻繁なホットフィックスがテストパイプラインの破損の症状であると感じていますが、これは事実ではありませんか？いずれにせよ、彼らはホットフィックスを取得してopsチームの作業を増やすためにリリースを繰り返す必要があります。さらに、ホットフィックスは通常、極端な時間的プレッシャーの下でコーディングされます。つまり、通常の作業よりも品質が低くなる可能性があります。

</コメントからコピー>

• 直前のホットフィックス -上記の懸念は、合理的なように見えます。また、壊れたテストパイプラインへの参照もあります。この更新により、新しいコード統合が月曜日にブロックされるという以前の注意は、パイプラインの破損（より正確な言葉が争われると思います）のもう1つの症状のように聞こえます。競合とは、次のことを意味します。単一のブランチを使用して、統合とリリースという2つの目的を同時に果たします。リリースが近づくと、これらの2つの目的は互いに衝突し始め、競合する要件を押し進めます：統合目的は、継続的に開いているブランチ（Merge Early And Often）で最適に機能し、リリース安定性はブランチが封印されることでメリットがあります（分離）可能な限り長い。A-haパズルのパーツが一致し始めたようです...

..見てください、月曜日のフリーズは競合する目的に役立つ妥協のように見えます：開発者は新しいコード統合のブロックに苦しみますが、テスターはこのブロックが短すぎるために苦しみます。

上記のように、専用のブランチ（統合以外）からリリースすることをお勧めします。このブランチが統合のように長生きするか、機能ブランチのように短命になるか（「機能」はリリースです）-それはあなた次第です。それは分離するだけです。

考えてみてください。現在、リリースを便利に安定させるのに1日では足りないと思いますか？新しい分岐戦略では、1つではなくリリースの2日前に分岐するだけで問題ありません。2日でも足りない場合は、3日前に分岐するなどしてください。新しいブランチを統合ブランチにマージすることをブロックしないため、リリースブランチをできるだけ早く隔離できます。このモデルでは、統合ブランチを凍結する必要はまったくありません。開発者は、月曜日、火曜日、金曜日など、統合ブランチを継続的に使用できます。

この幸福のために支払う代償は、修正プログラムの複雑さです。これらは、1つではなく2つのブランチにマージする必要があります（リリース+統合）。これは、新しいモデルをテストするときに焦点を合わせる必要があるものです。関連するすべてを追跡します-2番目のブランチへのマージに費やす余分な労力、2番目のブランチへのマージを忘れる可能性があるリスクに関連する労力-すべて関連します。

テストの最後に、追跡したものを集計し、この余分な作業の量が許容できるかどうかを確認します。許容範囲内であれば、完了です。それ以外の場合は、現在のモデルに切り替えて、何が間違っていたかを分析し、他にどのように改善できるか考え始めます。

update2

<コメントからコピー>

私の目的は、反復内でテストされ、成果物（構成壁の背後または正面）を取得することです。これは、テスターが反復で実行された作業をテストしている場合にのみ達成できます（前の反復からのコードを安定化しない）。

</コメントからコピー>

そうですか。まあ、私はそのような方法で直接的な経験はありませんが、私たちの関連プロジェクトで反復的な種類のテストが成功しているのを見ました。私たちのプロジェクトは反対の方法で進められていたので、これらの反対のアプローチについては、直接比較する贅沢もありました。

私の観点からは、そのレースでは反復外テストのアプローチが優れているように見えました。ええ、彼らのプロジェクトは順調に進み、彼らのテスターは私たちよりも速くバグを検出しましたが、どういうわけかこれは助けにはなりませんでした。私たちのプロジェクトもうまくいき、どういうわけか、彼らよりも短い反復を行う余裕があり、それらよりもリリースが少なく（はるかに）少なく、開発者とテスターの間の緊張がより少なくなりました。

ところで、彼らの側でより速い検出にもかかわらず、我々はほぼ同じ平均バグ寿命を持っていることに成功しました（寿命は導入と検出の間ではなく導入と修正の間の時間です）。おそらく、私たちはここでわずかな優位性さえ持っていました。なぜなら、より短い反復とより少ないリリースで、平均して私たちの修正がユーザーよりも早く届くと主張できるからです。

要約すると、リリースコードラインの分離は、チームの生産性を向上させる可能性が高いと今でも信じています。

さらに考えて...

• リリースコードラインを分離することで、より良いチャンスが得られます。読み直すと、これが繰り返しテストを試みることを思いとどまる印象を与えるかもしれません。私はそうではないことを完全に明らかにしたいと思います。

あなたの場合、反復テストのアプローチは、それを達成する方法（スムーズなテストパイプライン）と主要な障害が何であるかを明確に理解しているようであるため、試してみるのは安全に見えます（... テスト）。そして、結局のところ、パイプラインを正しく実現するのが難しすぎる場合は、代替アプローチにフォールバックするオプションが常にあります。

ところで、障害に関しては、その場合に追跡する価値のある追加の障害は、開発者側でバグを再現できず、テスター側で修正を確認するのが遅い/遅れるなどの問題になります。これらは、修正プログラムで現在発生しているように、パイプラインもスタックする可能性があります。

ユーザーストーリーの性質とその数を知らずに、1週間のリリースサイクルは極端に思えます。上記のシナリオは複雑に計画されており、一連の異なるブランチ、マージポイント、ハンドオフ、環境、およびテストスイートが含まれます。質が悪い。これは、後続のリリースでドミノ効果をもたらす可能性があります。

私見では、スケジュールがきつすぎる。

より効果的な単体テストと環境固有の統合テストを記述することにより、コードカバレッジを向上させることができます。

ペアプログラミングやコードレビューを導入することでコードの品質を高めることができますが、それはさらに貴重な時間に食い尽くされます。

ユーザーストーリーポイントのより良い推定は、単一のリリースに入るユーザーストーリーを暗黙的に制限することにより、リスク率の分母を下げることによっても役立ちます。

全体として、適切なプラクティスがあり、極端なリリースサイクルを処理するための優れたシステムがあるように思えます。あなたは正しい道にいるようです。

コミット（またはプッシュ）によってテストが実行され、テストに合格すると展開が行われる実際の連続展開を使用しないのはなぜですか？

次に、変更が不明な場合は、別のブランチで変更を行います。これにより、テストは実行されますが、展開は行われません。

壊れたトランク/マスターを安定させようとすることには、それを安定させるだけでなく、より多くのストレスがあると思います。