2

多くのソフトウェア企業は、新しい機能を製品に迅速に段階的にリリースしていると自慢しています。大企業 X での私のバックエンド プロジェクトでは、大きなリリース (四半期に 1 回のリリース) があります。スクラムを使用して、2 週間のスプリントとシステム統合テストを、隣接するチームとクライアントの間で、本番環境にリリースする前の最終段階として行います (独自のテスト パックがあります)。私たちのチームは、バックエンド サービス (それぞれのテストのパック) に対してのみ、夜間の回帰テストとの継続的な統合を使用しています。また、Jira、git、nexus、コード レビュー用の stash、spock、junit、teamcity などの最新のアジャイル ツールも使用しています。

チームが忙しいため、チーム間で頻繁に統合テストを行う余裕はありません。QA 開発者によって記述された回帰テストには、最大で 10 時間かかります (テラビュートのデータを含むデータベースに対してチェックされる多くの機能があります)。私たちのすべてのバックエンド サービスは、何百もの消費者がいて 24 時間 365 日働くビジネスの観点から重要です。本番環境に移行するには、すべての消費者も統合テストを実行する必要があります。これには多くの調整と時間が必要です。私たちは常に週末の非稼働時間にリリースします。

したがって、迅速なリリースは非常にリスクが高く、時間がかかります。サクセスストーリーとクイックリリースを達成する方法を知りたいですか? これは本当に実行可能ですか？

4

3 に答える 3

5

私のコメントを要約します。「迅速な[頻繁な]リリースは非常にリスクが高く、時間がかかる」と言うのは間違いです。

小規模なリリースを行うことで、それらのリリースのテストの難しさが軽減されます。より頻繁にリリースする場合、リリースのサイズは小さくなり、変更される機能の数は少なくなります。

参照: Martin Fowler の FrequencyReducesDifficulty

小規模リリースと大規模リリースのリスクは、システムのアーキテクチャによってある程度異なります。絡み合ったモノリスがある場合、無関係なコンポーネントに影響を与える変更のリスクが高くなります。これを解決するには、コンポーネントを分割して、互いに分離する必要があります。

アーキテクチャが疎結合の場合、コンポーネント間の接続は少なくなります。したがって、各コンポーネントを個別にテストする方が簡単です。リリースは特定のコンポーネントのみになる可能性があります。毎回すべてをデプロイする必要はありません。

リリースを容易にするように設計することもできます。たとえば、可用性の高いシステムを使用している場合、古いバージョンと新しいバージョンを同時に実行してから、古いバージョンをシャットダウンして、フェイルオーバーが発生するようにすることができます。

1 つのビッグバンですべてを解放する必要はありません。地域ごとに、または特定のユーザーのセットごとに、段階的にロールアウトできます。

API にはコントラクトが必要です。それは単なる関数ではありません。ワイヤのフォーマットと動作。すべてのサービスがその契約を尊重することを知っている限り、それらは機能するはずです。優れた自動テストが役立つはずです。ここでも、大きな API を小さな API に分割することを検討してください。

「そのようなアプローチは多くの企業で機能しないということです」と言うのも疑わしいです。私が見た最大の障害は文化的なものです。人々は変化を望んでおらず、そのプロセスは確立されています。

頻繁にリリースするために、すべての問題を解決する必要はありません。新しい機能やサービスのためにそれを行うことから始めることができます. 始めてみないと絶対に始まらない。

于 2014-06-19T08:18:48.487 に答える
1

デイブの答えに追加します。配達のコストの観点から理由を説明しますが、それは少し誤解を招きます。

実際に問題になるのは、「失敗した」配信のコストです。配信は複雑/長く/複雑であるため、当然のことながら、配信はできるだけ少なくしたい (そして失敗をできるだけ少なくしたい) ことを望みます。それが 1 つの可能なアプローチです。そのためには、バグの数を最小限に抑える必要があります。パッチのリリースには時間がかかり、コストがかかるためです。

もう 1 つの可能なアプローチは、展開をより簡単にして、より頻繁に実行できるようにすることです。ワンクリックで展開できるようになると、失敗した場合のコストが低くなることがわかります。その理由は、バグのコストが低いためです。修正してクリック デプロイすることができます。これにより、(通常は) 出荷前のテストの量を減らすことができます。

驚くべきことに、個人的な経験に基づくと、焦点を絞ることの追加の利点、つまり開発してすぐに出荷することにより、ほとんどのバグがとにかく早期に発見されることに気付くかもしれません。また、ビッグバンシステムでは通常それほど考慮されていない別のカテゴリの欠陥があります: 仕様のバグです。言い換えれば、間違ったものを構築すると、通常は非常に高くつきます -- 継続的デリバリーではそうではありません: 出荷が安いということは、変更するのも安いということです。

于 2014-06-19T10:14:14.760 に答える
0

  • 自動化する

    • 回帰テストのために、チームに余分な作業が必要になることはありません。
    • 生産と顧客についても同じ
    • テストのための調整は必要ない / あまり必要ない
      • テストインフラストラクチャも自動的にセットアップします

  • より速く、より早いフィードバック

    • 統合テストと回帰テストを高速化し、現在最も時間がかかるものを見つけます
    • ビルドエージェントを追加するなどして、より頻繁に実行する

最終目標は毎週のリリースかもしれませんが、最初は毎月のリリースから始めてください。また、回帰テストは 1 時間ごとに行われます。

于 2014-09-03T03:09:17.577 に答える