23 ライフサイクル管理ガイドライン

この章では、ライフサイクル管理機能の使用に関するガイドラインを提供します。

この章の内容は次のとおりです。

23.1 認証タイプを選択するガイドライン

認証タイプを選択する前に、次の点を検討してください。
  • ファイル・ベースの認証:

    ファイル・システムを通じて、リポジトリに直接アクセスできます。

    ユーザーとリポジトリの間で保護レイヤーが削除されるため、回避する必要があります。ユーザーが誤って、または意図的にリポジトリ・データベースを破損する可能性があります。

  • HTTP Basic認証:

    ユーザー名とパスワードを使用するBasic認証を指定します。HTTPまたはHTTPSプロキシ・サーバーの使用もサポートされます。安全ではありません。

    パスワードは平文でネットワーク送信されます。セキュリティが優先される場合には、避けてください。

  • SSL認証:

    HTTP認証と同じですが、Secure Sockets Layer (SSL)を使用してネットワーク接続すべてを保護できます。

    インターネット上でVCS操作を実行するときに使用する必要があります。

  • SVN/Git Basic認証:

    svnserveによってサポートされるカスタムSVNプロトコル上の基本的なユーザー名およびパスワード認証。

    安全ではありません。パスワードは平文でネットワーク送信されます。セキュリティが優先される場合には、避けてください。

    ノート:

    Git Basic認証で使用されるのは、指定したGit URLだけです。ユーザー名やパスワードは使用しません。
  • SSH認証:

    SVN認証と同じですが、すべてのネットワーク認証をSSH上で送信します。

    SSHアカウントに大きく依存するインフラストラクチャがすでに存在し、ユーザーがすでにサーバー・マシンにシステム・アカウントを持っている場合に便利です。

23.2 ブランチの一般的なガイドライン

ブランチで従うべき一般的なガイドラインは、次のとおりです。
  • 今後の開発が行われるメインのコード行には、トランクを使用します。

  • 安定性の向上、バグ修正などのために、コードをリリースするときには、ブランチを使用します。

  • チームが地理的に離れていたり、機能で分かれていたりするなどの場合は、パラレル開発にブランチを使用します。

  • マージを最小化するには、ブランチを最小化し、パーソナル・ブランチは作成しないでください。

  • トランクと開発ブランチとの間で、またはリリース・メイン・ブランチとリリース開発ブランチとの間で常にマージを実行します。

    ノート:

    開発ブランチ間で直接マージは実行しません。これによって管理不能なコード・トラッキングが発生します。

  • トランクでリポジトリに構成されたVCSキーを忘れないでください。暗号化されたコンテンツを効果的に移入およびマージできるように、すべての開発ブランチに同じVCSキーを構成する必要があります。

23.3 タグ付けの一般的なガイドライン

タグ付けで従うべき一般的なガイドラインは、次のとおりです。
  • プロジェクト機能の開発が完了したら、関連するすべてのアーティファクトに部分タグを作成します。

  • デプロイメント・アーカイブを介してQAまたは本番にリリースされるオブジェクトを作成します。バグ修正やデバッグ中に、リリースされたオブジェクトを逆参照するときに便利です。

  • 開発トランクまたはブランチで定期的に(毎週、隔週、毎月)フル・タグを作成します。現在のコードに何か問題がある場合は、使用可能な前のフル・タグに戻すことができます。

  • パラレル開発チームは、リポジトリ・オブジェクトのサブセットを扱い、関連するオブジェクトのみに部分タグを作成することになっているため、開発ブランチを作成できるのは、オブジェクトのサブセットに対してのみです。

  • マージ中に何か問題があった場合にマージ前の状態を復元できるように、変更をマージしているトランクまたはブランチにフル・タグを作成します。

  • ブランチ・アーティファクトを直接マージするのは避けてください。かわりに、タグを介してブランチ・マージを実行します。マージする準備ができたオブジェクトにタグを作成し、そのタグを使用する他のブランチまたはトランクに変更をマージします。

  • 既存の作業リポジトリをデタッチまたは削除する前にタグを作成します。作業リポジトリ・オブジェクトのVCSコピーは、これらの操作の一部として削除されます。そのため、必要な場合には、タグを作成するとオブジェクトを元に戻せます。

23.4 1つの開発チームのブランチのガイドライン

1つの開発チームで従うブランチのガイドラインは、次のとおりです。
  • リリースが近くなるまで、開発にはトランクを使用します。

    様々な論理ポイントでタグを作成します。

  • リリースが近くなったら、リリース用に開発ブランチを作成します。

    • コードの安定性向上とバグ修正のためには、リリース・ブランチを使用します。

    • 次期リリース・アイテムを開発するには、トランクを使用します。

    • 様々な論理ポイントで、リリース・ブランチからトランクに変更をマージします。

  • 一般公開(GA)時。

    • リリース・ブランチでリリース・タグを作成します。

    • GAタグからデプロイメント・アーカイブを作成します。

    • GAタグからトランクに変更をマージします。

23.5 パラレル開発チームのブランチのガイドライン

パラレル開発チームで従うブランチのガイドラインは、次のとおりです。
  • トランクから、各パラレル・チーム用に個々の開発ブランチを作成します。

  • 様々な論理ポイントで、次のようにします。

    • チーム固有の開発ブランチにタグを作成します。

    • コードをトランクにマージします。

    • トランクから変更をマージする他のチームに通知します。

23.6 パラレル開発チーム用のリリース・ブランチのガイドライン

パラレル開発チームのリリース・ブランチを操作する際のガイドラインは、次のとおりです。
  • リリースに近いとき。

    • リリース用のメイン開発ブランチを、トランクから作成します。

    • リリースのメイン・ブランチから各チームの開発ブランチを作成します。

  • 様々な論理ポイントで、次のようにします。

    • チーム固有のリリース・ブランチにタグを作成します。

    • チームのリリース・ブランチからリリース・メインにコードをマージします。

    • リリース・メインから変更をマージする他のチームに通知します。

  • 一般公開(GA)時。

    • メイン・リリース・ブランチにGAタグを作成します。

    • GAタグからデプロイメント・アーカイブを作成します。

    • GAタグからトランクに、安定したリリース・コードをマージします。

23.7 開発中のバージョニングのガイドライン

開発中に従うべきバージョニングのガイドラインは、次のとおりです。
  • オブジェクトの各バージョン

    • 安定したチェック・ポイントでバージョンを作成します。より制御できるようになるので、自動バージョニングは避けてください。

    • 作業対象のフォルダで、バージョンが古くなった、またはバージョニングされていないオブジェクトを定期的に確認し、バージョンを作成します。

  • フォルダ・バージョン

    • 次の目的でフォルダ全体のスナップショットを保持するフォルダを作成します。

      • フォルダの比較

      • 削除、移動、名前変更したオブジェクトの状態をVCSと同期

      • 子を持つフォルダを後からリストア

      ノート:

      各オブジェクトのバージョニングは、フォルダのバージョニングとは別です。

  • 様々な論理ポイントでODIオブジェクトのバージョンを作成します。

  • ODIオブジェクトの一貫性を維持するために、関連するすべてのオブジェクトのバージョンをVCSで作成します。

  • 開発中の様々な論理ポイントでタグを作成します。

23.8 テスト環境と本番環境でのデプロイメントのガイドライン

テスト環境と本番環境でのデプロイメントのガイドラインは、次のとおりです。
  • オブジェクトをテストする準備ができたら、タグを作成します。

  • タグからデプロイメント・アーカイブ(DA)を作成します。

  • テスト環境でDAを適用します。

    • バグの報告。

    • バグを修正し新規のDAを作成する開発チーム。

    • 新しいDAのテストを続行。

  • すべてのバグが解決されたら、本番環境用にDAの準備ができます。

23.9 初期デプロイメントとパッチ適用のガイドライン

初期デプロイメントおよびバッチ適用で従うべきガイドラインは、次のとおりです。

初期デプロイメント・アーカイブ

  • リリースされるアーティファクトを適用する際に使用します。

  • リリースされたすべてのオブジェクトを含む必要があります。

  • 空のリポジトリで初期デプロイメントを実行します。

パッチ・デプロイメント・アーカイブ

  • バグ修正と機能強化をデプロイする際に使用します。

  • 修正または機能強化に関連するオブジェクトのみを含む必要があります。

  • 何か問題があった場合にロールバックできるように、パッチ・デプロイメント・アーカイブの適用中にロールバック・デプロイメント・アーカイブを作成します。