JIRA アプリケーション用ステージング サーバー環境の構築


このドキュメントでは、JIRA アプリケーションのエンタープライズ環境のセットアップに関するベストプラクティスについて説明します。

  • 変更管理に関する最適手法のアドバイス
  • 開発 / ステージング / プロダクション アーキテクチャのアドバイス
  • 非プロダクション サーバーのデプロイ方法に関する技術手順

仮定 :

  • このドキュメントでは、管理者は変更を定型化したいものと仮定しています。したがって、UI ベースの変更や、ファイルシステムの場所の指定に便利なデータベース設定ツールなどの個別ツールに関する説明は省きます。

このページの内容:

(warning) 注意:

  • このドキュメントで説明する手順は、JIRA プラットフォームバージョン 4.0 以降で機能します。
  • ステージング サーバーを起動する前に、このドキュメントを一読してください。プロダクション インスタンスへの接続に関連するリスクが存在するので注意が必要です。このドキュメントでそれらの注意点を指摘します。

1. アーキテクチャ方針

多くの場合、システム管理チームは、エンタープライズアプリケーションに対して、ステージング環境やフェイルオーバー設定などのアーキテクチャを確立することになります。このドキュメントのアドバイスは、組 織全体の方針を変更・置換を意図するものではありません。アトラシアンアプリケーションをステージング環境で取り扱う際、考慮すべき点を明らかにするものです 。

定義

このドキュメントの説明では、次のように用語を定義します :

  • プロダクション : 実稼働インスタンス。最小限のダウンタイムと十分なテスト済みの変更を要求。
  • ステージング : プロダクションの前段階の環境。システム管理チームは運用開始前に正確な手順を確立できる。
  • 開発 : 自由な環境。ユーザーは最先端の変更やリスクを伴う変更を試すことができる。 
アドバイス

アトラシアンアプリケーションが基幹系システムである場合、開発、ステージング、プロダクションの3段階アーキテクチャを推奨します。

  • ステージング環境は、システム管理者がプロダクション段階へ進む前に変更やアップグレードをテストすることが主要目的です。
  • 開発環境は、様々な事業単位が運用リクエストに先立って独自の変更をテストする場です。

2. ガバナンス方針

アーキテクチャに加えて、次のような変更管理方針の確立を推奨します :

  • プラグイン インストール リクエストのデプロイとテスト向けの方針作成。ある環境で非常に有用なプラグインが大規模基幹系システムでは適切でないことがあることに注意してください。
  • 開発環境のデータ更新をするスケジュールの公開。ユーザーがいつ変更を削除すべきか分かります。
  • あらゆるファイルの変更を保管するためのソースコントロール リポジトリの設定。いつ、誰によって変更が行われたかを示す履歴を管理できます。既存のものがない場合、Bitbucket が選択肢の 1 つです。ファイルの変更に加え、アップグレード手順、ステージングサーバーのリフレッシュ (下記参照)、ソース管理におけるその他のあらゆる定型チェンジセットを管理できます。
    (tick) ヒント: JIRA では、お使いのインストールにおけるあらゆる変更を管理するツールを装備しています。UI に表示されているシステム情報ページで ”modified files” を確認してみてください。インストール ディレクトリ内のどのファイルが変更されたのかを確認できます。

  • 新規ワークフローの作成 (管理者権限が必要) などの変更には、2 つのオプションがあります :
    1. 1 回のリクエストごとに、一時的に管理者権限を持つ管理者ユーザーを作成します。この管理者ユーザーを適切なグループに追加すれば、グループに必要な管理機能を実行することができます。管理者ユーザーは管理者機能の実行を完了後に、グループから削除されます。
    2. 開発サーバーをプロダクション データーがない状態に保ち 、開発サーバーにより多くの管理者権限を与えます。エンドユーザーに具体的なワークフローやスキーム設定を覚えさせ、プロダクションでそれらの手順を同じように実施させます。 

3. ステージング サーバーのリフレッシュ方法

ここでは、既存のステージング インストールを保有しているものと仮定しています。まだ持っていない場合は、早速この指示に従ってステージング環境を設定してください。 

ステージング サーバーの設定がプロダクション環境を妨害しないように十分配慮してください。ステージング (または開発) サーバーを起動する前に、下記ヒントを一読してください。

3.1 プロダクションのフルバックアップ作成

  1. ホーム ディレクトリをバックアップします。 プロダクション ホームディレクトリの場所に関しては、「JIRA Home Directory の設定」 を参照してください。
    (warning) JIRA アプリケーションのホーム ディレクトリ外に添付ファイルおよびインデックス ディレクトリがある場合は、それらをバックアップしてください。保存場所がわからない場合は、「ファイル添付を設定する」および「検索インデックス」を参照してください。
    (info) JIRA アプリケーションの添付ファイルのバックアップに関する詳細情報は、「データをバックアップする」を参照してください。
  2. インストール ディレクトリをバックアップします。 「JIRA インストールディレクトリ」 は、JIRA アプリケーションがインストールされた時に、JIRA アプリケーション ファイルとライブラリが展開されたディレクトリです。
  3. プロダクション データベースをバックアップします。  ネイティブ バックアップ ツールを使い、プロダクション データベースのスナップショットを取ります。

3.2 プロダクション バックアップ全体のステージング環境へのコピー

  1. ステージング サーバーをシャットダウンします。
  2. JIRA インストールとホーム ディレクトリをステージング サーバーに復元します。
  3. 新しく復元したインストール ディレクトリに新しく復元した JIRA アプリケーションのホーム ディレクトリを参照させます。
    1. Edit the jira-application.properties file located within the <jira-application-dir>/WEB-INF/classes subdirectory of your new Installation Directory.
    2. Update the jira.home property in this file to the path of the new JIRA application home directory to the path of your copied JIRA applications home directory.
    3. Save your updated jira-application.properties file.
    (tick) You can also set your JIRA application home Directory's location by defining an operating system environment variable JIRA_HOME. This value of this variable takes precedence over the value of the jira.home property in the jira-application.properties file in your JIRA installation directory. See Setting your JIRA Home Directory for details.
  4. ステージング データベースにご使用のデータベースを復元します。
    (warning)既存の JIRA インストールと共にデータベース ( jiradb など) を使用しており、ご使用の新しい JIRA インストールのデータベースが同じマシンまたはデータベース サーバーで実行されている場合、新しいデータベースを別の名前で作成します (たとえば、jiradb_440 for JIRA 4.4.0 など、直観的に理解できる名前)。 Oracle は、ピリオドまたはアンダースコア付きのスキーマ名をサポート していません。 新しいデータベースと古い JIRA アプリケーションデータベースのアクセス権限は同一にしてください。

3.3 ステージング環境に固有の設定

  1. ステージング データベースを参照するようにデータベース接続を設定します。JIRA ホームディレクトリのルートにある dbconfig.xml ファイル、または旧バージョンでは <JIRA インストール>/conf/server.xml にあるデータソースを編集します。
    (warning)細心の注意が必要です! ステージング環境がプロダクション データベースを参照しないようにしてください。 
  2. Email処理には2つのオプションがあります :
    1. ステージング サーバーで Email を無効にします。 新規 JIRA インストールで何らかの初期テストを実行する必要がある場合は、Email アクセスの無効化 を実行して、意図しないメール送信を防止できます。Email 機能をテストしたい場合は、Email を有効にしたままにできます。Email を有効のまま維持する場合は、特に次の点に注意してください。
      1. 作成ハンドラーとコメントハンドラー。プロダクション メール サーバーからメールを取得してしまうことがありえます。これらを無効にするには、[Administration] > [Advanced] > [Services]、または、データベースにある “serviceconfig” テーブルからこれらを削除してください。  
      2. フィルター登録。ユーザーは登録したフィルターに関する通知を受け取ることになります。データベースの “filtersubscription” テーブルからフィルター登録を削除してください。
      3. チケットのアップデート通知。Email通知を使用せずにテストするプロジェクトと、通知スキームを切り離してください。
    2. Email 機能を有効にしたまま、Email をテストするためステージング インスタンスを設定します :
      1. 次のガイドを参照してください : How to Prepare a Development Server's Mail Configuration

3.4 ステージング サーバーの再起動

ここまでで、サーバーを再起動する準備が整いました。再起動したら、前述の手順を安全に実行したことを実証するために次の事項を確認してください :

  1. データベースがプロダクションを参照していないことを確認します。このためには、 Viewing your System Information を参照してください。”Database URL” が適切な場所を指し示していることを確認します。
  2. Email が無効、または、開発サーバーに対して設定されていることを確認します 。また、システム情報を表示しているとき、'atlassian.mail.senddisabled' の行の 'JVM Input Arguments' を確認してください。前述した通り Email を開発サーバーに設定した場合、この行は存在しません。

3.5 起動後の修正

  1. インスタンス カラーの修正 。「JIRA アプリケーションのルック アンド フィール設定」を参照してください。この実行は、ユーザーがステージング サーバーにいることを確認するのに適しています。
  2. インスタンス ベース URL の修正「JIRA オプションの設定」を参照し、インスタンス URL をステージング URL に変更してください。
  3. URL ホワイトリストの検討。 接続を許可する URL を変更するときは、「ホワイトリストの設定」を参照してください。
  4. 開発ライセンスの適用。 「ライセンス FAQ」を参照し、ステージング サーバー用にライセンスを入手してください。ライセンスを適用するには、「JIRA アプリケーションのライセンス」を参照してください。
  5. applink の再設定。applink を使って他のサービスと接続している場合、そのインスタンスに対してサーバーID を変更する必要があります。
    (warning) applink を配置したままにすると、リンク生成時に、プロダクション インスタンスがステージ サーバーを参照することがありえます。
    1. Confluence: Confluence のサーバー ID を変更する方法
    2. JIRA アプリケーション: テストインストールのためのサーバー ID の変更
最終更新日: 2015 年 9 月 30 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.