このシリーズの前回と最初の記事では、DevOpsの新しいフォームとモデルを紹介し、その重要なコンポーネントとワークフローについて説明しました。
この記事では、アプリケーションのリリースサイクルの重要性と、DevOpsモデルでアプリケーションが果たす重要な役割について説明します。
しかし、始める前に、前回の記事、特にSDLCからいくつかの重要なセクションを簡単に思い出し、コンピュータサイエンス学界の私たちの多くが何十年も不注意にフォローしていた可能性があるという事実を再検討する必要があります。
前の記事はすでにここにリンクされているので、手順の詳細については説明しません。しかし、SDLC図をもう一度見てみましょう。
DevOpsにおけるソフトウェアリリースライフサイクルの重要性
ソフトウェアリリースライフサイクル（略してSRLC）は、アプリケーションの開発中に実行される必須の手順です。高品質のソフトウェアが高品質のDevOpsを保証するため、これは非常に重要です。これは、さまざまなフェーズが効率的に進行した場合にのみ効果的に保証できます。
ソフトウェアリリースライフサイクル（SRLC）は、ソフトウェアの開発がプレアルファフェーズからプロダクションフェーズに進化するさまざまな段階のシーケンスです。すべてのソフトウェアは、保守終了（EOL）に達するまで、またそれがない限り、常に更新されたバージョンを持つため、これは継続的なプロセスです。
名前と慣行は、開発者ごとに異なります。ただし、一般的に、関連する5つの重要なフェーズがあります。
- プレアルファ ：ソフトウェアリリースの最初のフェーズで、主要な機能のみが含まれ、バグの数が最も多い可能性があります。開発者とテスターによってのみテストされます。
- アルファ ：ソフトウェアリリースの第2フェーズは機能が完了していると見なされ、まだバグがある可能性がありますが、プレアルファよりはるかに少ないです。開発者とテスターによってテストされます。ただし、多様なNDAに応じて、選択的または世界中で一般に公開することもできます。
- ベータ ：第3フェーズは、主に前の2つのフェーズで発生したバグと問題の修正に焦点を当てています。プレアルファ版と同様に、ベータ版ソフトウェアの可用性もNDAに基づいています。
- リリース候補 ：ソフトウェアのリリース候補バージョンはプレリリースバージョンであり、最終的に安定した製品になる可能性があります。一般的に、リリース候補バージョンは、プログラムへの新しいソースコードを受け取りません。ソースコードへの変更は、本番レベルのテストを受けたときにエラーが発生した場合にのみ行われます。
- 本番リリース ：非常に明白なように、製品リリースは、安定した製品として一般に公開される最終製品です。
注 ：NDAの概念は、透過的なモデルであるため、オープンソースソフトウェアの分野ではあまり価値がありません。
新しいモデルに基づいて、SRLCは実際には2つの段階で機能します。
1。 ADLCの開発リリース段階
アプリケーションはこの段階で最初のバージョンになり、より成熟して実行可能になるにつれて、リリースフェーズの大部分（上記）を経て進行します。バグは徐々に減少し、時間の経過とともに効率が向上します。
2。 SDLCの安定したリリース段階
これはSRLCの実稼働段階であり、開発リリースは、クライアントとユーザーがすぐに使用できる最初の安定バージョンになります。
何十年もの間、ソフトウェアエンジニアリングの学問分野で 、さまざまな大学のコンピュータサイエンスのカリキュラムでは、ソフトウェアリリースプロセスモデルがサイクルとして言及されています。しかし、描かれている図はかなり矛盾しています。通常、次のように説明されます。
簡単な観察に基づいて、上の図が「サイクルのような」特性をまったく示していないことは非常に明白です。この従来のモデルに基づいて、図にはそのような特性は示されていませんが、サイクルと呼ばれています…サイクルとは言えません…フローチャートです。
サイクルのように見せるために、本番フェーズはプレアルファフェーズに戻る必要があります。シナリオ全体をもう一度批判的にレビューしない限り、それは論理的に意味がありません。
安定版リリースでは、ソフトウェアがその潜在能力を最大限に発揮し、本番環境に展開できるようになっていることがはっきりとわかります。図には表示されていませんが、なぜ「ライフサイクル」と呼ばれるのですか？
理由は次のとおりです
製品リリースがユーザー/クライアントに採用された場合でも、ソフトウェアの開発者は、機能の追加、既存の機能の調整、本番環境でのバグやセキュリティの不具合の修正、および時間の経過とともに必要となるその他の変更によって、ソフトウェアの改善を続けています。 。したがって、開発バージョンは常に舞台裏で常に機能しています。
ソフトウェアを批判的にテストしたとしても、実際のシナリオでのみ明らかになる特定の欠陥があり、これらの欠陥はすべての製品リリースの更新バージョンで修正されています。
少し考えてみましょう。ソフトウェアが更新されたバージョンの形で継続的に開発されている場合、製品リリースを実際に最終製品と呼ぶことができますか？
図とそのシナリオを実際のサイクルとして確認するにはどうすればよいですか？
このプロセスをサイクルとして認識できるようにするには、前述の新しいSDLCモデルを再検討する必要があります。
ソフトウェアリリースの観点からのみ見たい場合は、SDLCモデルをSRLCに変換できます。
ソフトウェアアプリケーションはその開発のみに関係しますが、ソフトウェアシステムは、アプリケーションと、アプリケーションが展開および保守されるシステムプロセスの両方の開発に関係します。さらに単純化すると、次のように再構想できます。
開発リリースにズームインしてみましょう 実際に何が起こっているのかを見て、「ライフサイクル」を導き出すためのゾーン：
ここでは、最初の4つの重要なフェーズが実際のサイクルの一部として表されていることがわかります。これらの各フェーズでは、アプリケーション開発も行われます。 ADLC（図ではADLCとラベル付けされています）に基づいて、次のフェーズに進みます。ソフトウェア開発がリリース候補段階を終了すると、システム開発が行われます。 SDLC（図ではSDLCとラベル付けされています）に基づいて、最終的に安定したリリースになり、エンドユーザーやクライアントの環境などの実稼働環境でアクティブになります。
なぜ安定リリースをプレアルファ状態に戻さなければならないのですか？自分自身をライフサイクルとして表現するだけですか？絶対にありません。
安定したリリースでは、可能な限り最高の品質を一貫して維持するために、プレアルファレベルのスクリーニングを再実行する必要があります。
製品はすでに安定バージョンとしてリリースされているため、プレアルファ、アルファ、ベータフェーズでのデバッグとテストにそれほど時間はかかりません。したがって、新製品が一般にリリースされた後、それが実際に展開され、あらゆる種類のユーザーによって監査された後、すぐにリリース候補レベルのスクリーニングに近づくことを覚えておく必要があります。
リアルタイムの本番レベルのバグは避けられませんが、自然が存在する場合でも、プレアルファアプローチでそれらを再評価する必要があります。そうして初めて、最適な速度と効率で高品質のソフトウェアを一貫して保証できます。
したがって、この改訂されたモデルは、最終的に実際のサイクルと呼ぶことができ、開発コミュニティの多くの人が何十年も不注意にフォローしていた可能性のある従来のフローチャートではありません。これは継続的なプロセスであるため、ソフトウェアリリースの「ライフサイクル」と呼ばれています。
このトピックに関する提案、フィードバック、またはコメントがある場合は、以下のセクションでお知らせください。このような興味深いアプローチにぜひご参加ください。このシリーズの次の記事をお楽しみに:)