ソフトウェアをリリースするまでのプロセス

未開拓のグリーンフィールド環境での新システムの設定は、無敵状態でのプレーと似ています。これには、すべてのコンポーネントの互換性が完璧である、すべてが正しいバージョンを持っている、すべてのテストを自由に実施し、安心してすべてを確認することができる、というメリットがあります。開発やテストに使っていたシステムを本番システムに移行するだけであるため、事実上「本番稼動」は形式的に行われます。しかし、製品のライフサイクルにおいて、新たな拡張や 更新が複数回行われるような困難に直面した場合、どうすればよいのでしょうか。実際、稼働中のシステムへの干渉は、選択肢としては非現実的であり、その一連の作業には大きな負担と責任が伴います。従って、専用の段階的プロセスがより良い選択肢となるでしょう。

新製品やサービスが市場に出る時、最終工程が完了し、出荷準備が整うまでの一連の長い段階を経ています。各コンポーネントの開発や長期間に渡る複雑なテストから、最終的な品質確認とリリースに至るまで、製品ライフサイクルは基本的に個別のプロセスが連なった長いサイクルになっています。従って、各フェーズがそれぞれ独立したサーバー環境を持ち、望ましくない影響がその後のフェーズに波及しないようにすることが理想的です。

開発者は、特定の既知の条件（例：特定のバージョンのOS、特定のコンパイラ、特定のライブラリやフレームワークのセット）の下で、別の開発システム（D）で作業を行います。Dシステム上で、開発者は最終的なリリースまでのソフトウェアの各状態を作成します。

品質チェックは、Dシステムと同じ条件・パラメーターを持つ、全く別のシステム（Q）で行われます。Qシステムでテストを行い、最終バージョンまでの各状態を確認します。そして最終的に、品質チェックをクリアしたバージョンが、実際の生産システム（P）に展開され、現場のユーザーへ提供されるのです。

プロセスを段階化させるこのアプローチでは、テストシステムや本番システムの中断や停止を防ぐことができます。特に、サードパーティーコンポーネント（ツール、ライブラリ、データベース、またはOS全体）の更新が関係する場合、システムの安定性に深刻な影響を与える恐れがありますが、他のメーカーのコンポーネントとうまく連携するよう設計されているケースはごくわずかです。Dシステムでは、リスクを伴うことなく、更新が既存システムに与える影響を評価することができます。全てのコンポーネントが正常に動作することを確認できた場合にのみ、Qシステムでテスト・品質チェックを行い、最終的にPシステムへと展開します。

Wibu-Systemsにおいても、CodeMeter License Centralのプロセスの段階化を推奨しています。特にカスタマイズされたCodeMeter License Centralの拡張機能が関係する場合、新しいバージョンへのアップグレードは、システム全体との互換性をテストし、事前に確認する必要があります。これは、既に述べた、DからQ、QからPへの移行プロセスがあれば容易に実施することができます。また、このようなチェーンの構築とメンテナンスをWibu-Systemsの認定データセンターへ委託することも可能です。

適切な人材と準備さえあれば、新たな拡張や更新も怖くありません。

 

KEYnote 44 – Edition Fall/Winter 2022