注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

リリース管理

リリース管理は、異なる目的に対応する複数の環境にわたってリソースの複数バージョンを管理するプロセスであり、環境分離の原則とも呼ばれます。通常、これらの環境はリリースの異なる段階にあるリソースのための独立した場所として機能します。たとえば、機能の開発、機能のテスト、そして本番環境への機能のデプロイなどです。

たとえば、組織の開発者は開発環境で新しい機能の共同作業を行い、ユーザー受け入れテスターや自動テストスクリプトはテスト環境で本番環境にリリースされる前の機能をテストできます。この間、既存の本番環境で稼働している機能はユーザーに提供され続け、他の環境での開発やテストによる影響を受けません。

リソースを環境に分離することで、変更を本番環境に影響を与えない制御された環境でテストおよび検証できます。リソースがテストされた後、準備が整えば本番環境に昇格させるか、必要に応じてさらに開発を進めることができます。

以下に示すように、DevOpsとMarketplaceを使用することはリリース管理プロセスを実装する1つの方法です。Palantirプラットフォームでは、Foundry Branchingを使用するなど、他の方法もあります。

DevOpsとMarketplaceを使用したリリース管理

リソースをリリース管理するには、まず開発された環境からリソースをパッケージ化し、他の環境にデプロイできるようにする必要があります。DevOpsを使用してリソースをプロダクトにパッケージ化できます。

リソースがプロダクトにパッケージ化されたら、それをデプロイする必要があります。Marketplaceを使用してプロダクトをインストールし、プロダクトインストールを管理し、リリースを環境に昇格させます。

Palantirプラットフォーム内では、環境分離のためにスペースを使用します。

環境分離のためのスペースを設定する

スペースは、Foundryで環境分離を可能にする柔軟なプリミティブです。環境分離は、開発やデプロイの異なる段階のために独立したスペースを維持する慣行であり、たとえば開発、テスト、本番環境などです。この分離により、変更を本番環境に昇格させる前に制御された環境でテストおよび検証でき、本番ワークフローにエラーや問題を導入するリスクを最小限に抑えます。

ワークフローに必要なだけ多くの環境を作成できるため、他のリリース管理モデルも可能です。

一般的な環境セットアップは、Palantirプラットフォームで「スペース」として表される次の3つの環境で構成されます。

  • 開発: 新しい機能を開発する環境
  • テスト: 前の環境で開発された機能を手動または自動でテストする環境
  • 本番: 前の環境で開発およびテストされた機能をエンドユーザーが利用する環境

スペースは柔軟なプリミティブです。ワークフローに必要なだけ多くの環境を作成できるため、他のリリース管理モデルも可能です。

Diagram that shows three workflows that are deployed across three environments.

一般的に、プロダクトが環境を通じて昇格されると、そのプロダクト内の機能が指定された環境/スペースで利用可能になります。環境間で以下の違いを設定できます。

  • 環境固有のデータ: たとえば、開発環境では仮想データを使用し、テスト環境では実データのサブセットを使用し、本番環境では実データの全規模を使用します。
  • 環境固有の動作: 非本番環境の動作は、本番環境の動作とは異なる場合があります。たとえば、本番環境内の関連ユーザーに送信されるメール通知が、他の環境では異なるグループに送信される場合があります。同様に、非本番環境での承認ワークフローは、テスターや開発者などの異なるユーザーが承認を行うことを許可する場合がありますが、本番環境では実際の承認者が行います。
  • 環境固有の統合: たとえば、開発環境は開発レベルのデータベースに接続し、他の開発レベルのシステムのAPIを呼び出します。本番環境は通常、本番データベースに接続し、他の本番レベルのシステムのAPIを呼び出します。

Foundry Branching とリリース管理の比較

Foundry Branchingは、ワークフローの変更を隔離されたブランチで開発およびテストすることを可能にし、複数の開発者が独立して作業できるようにすることで、環境内の変更を管理するのに最適です。機能が完了し、適切な権限を持つユーザーによってのみメインブランチにマージされます。

Foundry Branchingは迅速な反復に最適で、新しく開発された機能を簡単にテストできます。しかし、ブランチの短命な性質とリソースタイプのカバー範囲の制限により、リリース管理のすべてのニーズを満たすわけではありません。

DevOpsとMarketplaceを使用したリリース管理の利点には、以下のようなものがあります。

  • 異なる環境で異なるソースシステムと統合する能力
  • 環境間で異なるセキュリティポリシーを維持する能力
  • 前のリリースにロールバックする能力
  • リリースチャネルを設定する能力
  • 長期間存在する環境をサポートする能力

Foundry Branchingを使用したリリース管理の利点には、以下のようなものがあります。

  • 新しい機能を迅速に反復し、簡単にエンドユーザーにリリースする能力
  • 環境にホットフィックスを簡単に作成してリリースする能力
  • 使用されていないブランチが自動的に削除されるため、インフラストラクチャのコストが低くなること

DevOpsを使用したリリース管理の方法についてさらに学びます。