概要

本ドキュメントは、開発から本番環境へ Jira 設定を実装するためのベスト プラクティスについて説明します。Botron の Configuration Manager アドオンを使用して、本番環境へロールアウトする前に、対象の変更を効果的にテストできます。 

定義

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

• 開発 : 自由な環境または多くの環境。ユーザーは最先端の変更やリスクを伴う変更を試すことができる。

• ステージング : プロダクションの前のステージの環境。システム管理チームは運用開始前に正確な手順を確立できる。ステージングは本番環境のクローンまたは本番環境に近いレプリカにする必要があります。 

• プロダクション – 実稼働インスタンス。最小限のダウンタイムと十分にテスト済みの変更を想定。
• 設定スナップショット は Configuration Manager for Jira アドオンを使用して作成され、Jira 設定オブジェクト の状態と、その時点での互いの関係を表します。2 種類の設定スナップショットがあります。
  • プロジェクト スナップショット - 選択した多数のプロジェクトの構成を含みます (スキーム、ワークフロー、フィールドなど)。
  • システム スナップショット– 1 つの Jira インスタンスの設定全体 (プロジェクト、ワークフロー、スキーム、画面など) を含みます。

アーキテクチャ戦略に関する推奨事項

Jira をクリティカルなシステムとして運用している場合、開発、ステージング、本番環境で構成される 3 層アーキテクチャ戦略をお勧めします。

Jira がクリティカルなシステムではない場合、開発と本番環境の 2 層戦略を使用できます。

計画

環境 (ハードウェア) を準備する

ステージングは、本番環境サーバーに使用されているハードウェアと可能な限り近づける必要があります。デプロイメントはどのタイプのハードウェアにすることもできますが、一般的なガイドラインも、本番環境にできるだけ近づけることです。

ステージングを同期させる

ステージング環境は、変更を本番環境に導入する前の最終確認の場として使用されます。最終確認が正確に行われていることを確認し、実際のデプロイメントで予期せぬ事象が発生するのを防ぐため、ステージングは本番環境と同一の複製にする必要があります。

本番環境で使用されるハードウェアのタイプに応じて、ステージングを同期させるオプションがいくつかあります。

• 物理ハードウェア - ステージングの同期を維持するには、データベースおよびファイルシステムで使用されているストレージを複製するか、Jira バックアップ / 復元手順に従います。
• 仮想マシン - 本番環境のスナップショットを作成し、このスナップショットから新しい仮想マシンを作成します。
• Configuration Manager  – ステージング サーバー設定を本番環境へ復元できる独自の機能。

Configuration Manager for Jira

Botron の Configuration Manager for Jira アドオンが各 Jira サーバーにインストールされている必要があります。 

トラッキング

Jira のセットアップおよび構成に対するすべての変更を、リクエスト チケットの変更経由で追跡することをお勧めします。変更チケットはライフサイクルを通じて、選択された実装パスに従い、最初のユーザー リクエストや追加情報 (設定スナップショット、変更 / 影響分析、期間など) を含む必要があります。

破壊的な変更

推奨される IT プラクティスは、緊急でないすべての修正を定義済みのリズム (例: 金曜午後 1 時から 3 時) で導入することです。導入された変更は、2 つのグループ (破壊的と非破壊的) にセグメント化できます。前者は、ユーザー アクセスが制限されている定義済みのメンテナンス時間にのみ導入できます。

コミュニケーション戦略

導入される変更について Jira ユーザーに伝えるためのコミュニケーション戦略を検討します。この情報には変更ロールアウトの正確な日付と包括的な概要が含まれます。変更のリクエスト チケットへのリンクも含めることができます。
コミュニケーション戦略はメール、通知バナー、またはその他の内部の標準的な社内連絡方法で実行されます。ユーザーに 5 回以上通知することを推奨します。

• 変更を導入する 1 週間前
• 1 日の始め
• 1 時間前
• 直前の通知
• 変更の導入後の、成功/失敗を示すメッセージ。

システム ヘルス

3 台のサーバーすべてでシステム ヘルスを評価し、整合性チェック エラーがある場合は解決する必要があります。

3 層アーキテクチャ戦略のステージ

このセクションでは、3 層アーキテクチャ戦略を使用して Jira 本番環境に変更を公開するプロセスについて説明します。図に示したプロセスを行うには、Configuration Manager for Jira アドオンをインストールしている必要があります。このアドオンでは、異なる環境間で設定スナップショットを作成してデプロイすることができます。アドオンは各環境にインストールする必要があります。ライセンスの詳細については、FAQ セクションを参照してください。

ステージ 1 (開発)

ステージ 1 の概要:

• 環境: 開発環境
• 目標: 新しいプロジェクト設定を開発する、ユーザー承認テストを実現する、ステージング環境に実装可能な設定スナップショットを作成する。
• ユーザー: ビジネス ユーザーまたは管理者。Jira 設定の知識を持つ任意のユーザー
• 必要なツール: Configuration Manager for Jira

このプロセスの最初のステージは開発環境で実施されます。一般的な対象ユーザーは、ビジネス ユーザーまたは管理者、Jira 設定の知識を持つ任意のユーザーです。

このステージの手順は次のとおりです。

1. 新しいプロジェクト設定の開発 - プロジェクト設定には複数の設定エレメントを含めることができます (例: ワークフロー、カスタム フィールド、画面など)。
2. 新しい設定が行われると、設定が正しいことを確認するため、ユーザー受け入れテストが実行されます。
3. ステージング環境へ実装できる設定スナップショットを作成します。
   
   
   
   
4. 設定スナップショットをダウンロードします (Jira 設定がチケット経由で追跡されている場合、スナップショットを適切なチケットに添付する必要があります)。

ステージ 2 (ステージング)

ステージ 2 の概要:

• 環境: ステージング環境
• 目標: 提案された設定の変更の検証、変更と影響の審査、コミュニケーション計画の準備、必要なダウンタイムの見積もり、および本番環境ロールアウト手順の明確化。
• ユーザー: Jira システム管理者
• 必要なツール: Configuration Manager for Jira

このプロセスの第 2 ステージはステージング環境で実施され、導入された変更が他のプロジェクトへ影響しないことを確認するための包括的な検証を、Jira システム管理者が行います。変更と影響は異なります。たとえば、ワークフロー ステータス名を変更 ("完了" から "承認済") すると、会社ポリシーと干渉したり、報告に使用されている JQL フィルターが壊れる可能性があります。影響の一般的な例として、通知スキームの変更を実施した場合、その変更は本番環境の他のプロジェクトへ影響する可能性が高くなります。

このステージの手順は次のとおりです。

1. 設定スナップショットをデプロイし、構成変更案を評価します。
   
   
   
   
2. 新しい構成案の変更と影響を評価することは非常に重要です。結果がマイナスな場合は、開発に戻ります。
3. 正式に導入する前にユーザーに変更を伝えます。
4. 必要なダウンタイムを見積もり、必要なデプロイメント時間を測定してチケットを更新することで、本番環境ロールアウト手順を明確化します。

ステージ 3 (本番環境)

第 3 段階の概要:

• 環境: 本番環境
• 目標: 設定の変更を本番環境にロールアウトする
• ユーザー: Jira システム管理者
• 必要なツール: Configuration Manager for Jira

この段階の 3 番目、かつ最後のステージは、本番環境への設定の変更のロールアウトが含まれます。前のステージの変更結果および影響分析によって、競合や望まない結果が出ないことを確認した後で、デプロイメントを本番環境へ進めます。

このステージの手順は次のとおりです。

1. 必要なコミュニケーション計画を実行します。
2. バックアップの構成のスナップショットを作成します。
3. ユーザー アクセスの制限 - ユーザーのアクセスが制限されるメンテナンス期間中に本番環境サーバーへの変更を実行します (強力な要件ではありませんが、推奨されるベスト プラクティスです)。
4. 設定スナップショットをデプロイします。
5. 監査ログに警告がないかどうか確認します。
   
   
   
   

6. SUCCESS/FAILURE  を宣言する– デプロイメント結果に基づきます。成功し、ユーザーへのアクセスが制限されている場合、すべてのユーザーに伝え、システムをオープンにします。

7. FAILURE の場合 – 本番環境サーバーのスナップショットを復元して再起動します。ステージング サーバーが本番環境と同一の場合、この時点でのエラーは発生しないはずです。

アドオン データの移動

アドオン データの移行は、これまでに遭遇した最も一般的なポータビリティの課題の一つです。このセクションでは、アドオン データを効果的に移行するさまざまなオプションを探索します。

各アドオンで作成され、保存されたデータは、使用状況はストレージ メカニズムに基づいて分類されます。

• ユーザーが作成したデータ。例えば、構造アドオンによって作成された階層構造には、ユーザーが作成および消費したデータが含まれます。これは、プロジェクト、システム、またはアドオン設定には関係しません。Configuration Manager for Jira はこのデータ タイプは処理しないため、アドオンのエクスポート / インポート機能を利用する必要があります。
• 設定データ。アドオン設定は、ワークフローの事後操作 / 条件 / バリデーター、カスタム フィールド、ダッシュボード ガジェット、およびその他の Jira オブジェクトに影響したり、アドオンに対して非公開にしてデータベース内に保存したりできます (例: アクティブ オブジェクトを使用)。Configuration Manager にはすぐに利用できる複数のアドオンが含まれます。アドオン ベンダーが Configuration Manager で提供された API を実装すると、その他のアドオンとの互換性も容易に確保できます。

制限と回避策

設定ロールアウト中に考慮すべき特定のシステム制限事項があります。例:

• アドオン データ: 特定のアドオン カスタム フィールド設定、アドオン ワークフロー プロパティ設定、Jira 設定オブジェクト外のその他のアドオン データは含まれない場合があります。
• Jira Service Desk  – Jira Service Desk 固有の設定はサポートされません。Configuration Manager の将来のリリースで追加される予定です。
• 6.x から 7.x での設定オブジェクトの違い – これは、ターゲットと異なる Jira のメジャー バージョンでスナップショットを作成したときに考慮する必要があります。7.x では一部の権限タイプが削除され (例: USE グローバル権限はアプリケーション ロールに置き換えられました)、その他のさまざまな設定オブジェクト、具体的には権限スキームの権限 (例: スプリントの管理)、セキュリティ レベル タイプ (アプリケーション ロール)、表示権限 (ログインしているユーザー) が導入されています。

制約や、その他の既知の問題に関する回避策案:

• スクリプト – Configuration Manager for Jira で処理されないデータを移行するために API レベルのスクリプトを開発できます。スクリプト開発には ScriptRunner アドオンを使用できます。
  
• 手動 - 設定の量が少ない場合、ターゲット Jira に手動で追加できます。
  
• プロフェッショナル サービス - Botron のソリューション アーキテクト チームは、あらゆるタイプのデータを移行するカスタム ソリューションを開発できます。
  

一般的な課題

デプロイメントの際に、データの携帯性プロセスに悪影響を及ぼす可能性がある、いくつかの一般的な課題を特定しました。これらの最も一般的な課題の例:

• スナップショットの作成/デプロイメントの妨げとなる整合性チェック エラー。ターゲット/本番環境サーバーの整合性を保持するため。スナップショットを作成またはデプロイするたびに Configuration Manager 整合性チェック が実行されます。続行するには、報告されたすべての重大エラーを解決する必要があります。詳細は、こちらで入手できます。
• Jira バージョンの違い - ソースとターゲットの Jira バージョン (特にメジャー バージョン) の違い。
• アプリケーション権限 / ライセンス - 7.x の場合、デプロイメントを実行するユーザーがソフトウェア プロジェクトを作成する権限を持たない、または Jira Software アプリケーションがインストールされていない / ライセンスがない。
• ユーザー ディレクトリの不一致 - テスト/ステージ/本番環境が同じユーザー ディレクトリを使用していない場合、新しいプロジェクトがデプロイされ、ターゲットのユーザー ディレクトリ内にプロジェクトのリードが存在していない場合、ユーザーの作成が必要となる場合があります。
• プロキシ/ファイアウォール: 大きなインスタンスでのスナップショットの作成時やデプロイ時の分析前に、問題となる可能性があります。それ以外の場合、デプロイメント自体に問題はありません。これは、プロキシ サーバーのタイムアウト限度を増やし、ファイアウォールのブロック ルールを無効化することで回避できます。

よくある質問

1. 設定全体が Configuration Manager for Jira を使用して自動的に本番環境に移動されますか?
   はい。設定スナップショットで取得されたすべての設定がロールアウトされます。スナップショットに含まれる、サポートされるオブジェクト タイプはこちらに記載されています。
2. 新しいサーバー インスタンスから古いサーバー インスタンスにプロジェクト設定の変更をロールアウトすることはできますか?
   本番環境サーバーとステージング サーバーは同じバージョンにすることを強くお勧めします。Configuration Manager を使用すると、異なるバージョン間でデプロイメントを実行できますが、その警告が表示されます。新しいバージョンで作成されたスナップショットは、古いバージョンには存在しなかった新しい設定オブジェクトが含まれている可能性があるため、古いものでは機能しない可能性があります。たとえば、Jira 7.x には、6.4.x に存在しなかった新しい権限があります。
   
   
3. 設定スナップショットのデプロイにはどのくらい時間がかかりますか?
   ほとんどの場合、プロジェクト設定スナップショットには数秒から 1 分かかります。数百のプロジェクト、数千のフィルター、および数百件のアジャイル ボード含む大規模なシステム スナップショットでは、デプロイに 1 以上かかる場合があります。ステージングの際に、正確なデプロイメント時間の見積もりを得る必要があります。
   
   
4. デプロイメント中にエラーが発生したらどうなりますか?そのターゲット/本番環境インスタンスは壊れてしまいますか?Configuration Manager によってデプロイされたすべての変更は単一のトランザクション内で実行されます。エラーが発生した場合、トランザクション 全体がロールバックされるため、サーバー設定はすべての変更が正常にデプロイされたときにのみ変更されます。
   
   
5. スナップショットの作成とデプロイメントを自動化できますか?
   はい。Configuration Manager はこのために公式 REST API を提供しています。
   
   
6. 整合性チェックのエラーにより、設定スナップショットを作成できません。なぜこのような制約があるのですか?この問題を解決するにはどうすればよいですか?
   整合性チェックのエラー は重大な問題を示している可能性ああります。それ以外の重要でないエラーは警告とマークされ、スナップショットの作成/デプロイメントの障害にはなりません。重大エラーがある設定のデプロイメントを許可しないことにより、Configuration Manager は本番環境システムが、動作しないもので変更されるのを防ぎます。
   
   
7. Configuration Manager はカスタム アドオンを処理できますか?
   はい。Configuration Manager はあらゆるカスタム アドオンを処理するよう拡張できます。詳細は、Botron の サービス チームにお問合せください。

お困りですか?

自分で問題を解決できない場合、次の通信チャンネル経由でサポートまでお問い合わせいただけます。

• • support@botronsoft.com にメールを送信します。
  • トレーニングまたはサービス固有の情報については、services@botronsoft.com にお問い合せください。