メインコンテンツまでスキップ

アップデートとパッチ適用

intra-martでは、製品を安定して利用するため、機能改善や不具合修正を目的としたアップデートおよびパッチを提供しています。ここでは、年2回実施されるアップデートと、随時提供されるパッチの適用手順について説明します。適用にあたっては、事前に影響範囲を確認してください。

アップデートとパッチ適用の概要​

intra-martのアップデート​

intra-martでは、原則として年2回のアップデートを提供しています。アップデートには、機能強化やセキュリティ対応、不具合修正などが含まれるため、常に最新バージョンを利用できるよう準備しておくことが重要です。

参考

intra-martの最新アップデート情報は、「intra-mart Developer Portal - 最新情報」を参照してください。バージョンアップに伴う主な機能強化・追加・変更点の概要も確認できます。

コラム

現在お使いのバージョンは、次のいずれかの方法で確認できます。

  • システム管理画面のホーム画面
  • WARファイルのWEB-INF/juggling.structure.txt
  • Resin起動時にsystem.logに出力されるログ

intra-martのパッチ適用​

intra-martでは、製品のアップデートとは別に、緊急性の高い不具合修正や要望対応を含むパッチを提供しています。パッチには不具合修正やセキュリティ対応が含まれるため、システムの安定運用の観点から速やかな適用が重要です。

参考

intra-martの脆弱性に関する要件は、「intra-mart 要件情報公開サイト」を参照してください。パッチは、過去1年の間にリリースされたアップデートに対して提供しています。

アップデート／パッチ適用手順（標準的な流れ）​

アップデート／パッチ適用作業は、原則として事前準備とテスト環境での確認を行った上で、本番運用環境へ同様の手順で反映します。必要に応じてロールバックできるよう準備しておくことを推奨します。

1. 事前準備​

アップデート／パッチ適用作業を安全に実施するため、事前に以下の内容を確認・準備します。

(1) 目的と対象範囲の明確化
既存環境における対象のサーバ（開発環境・検証環境・本番環境）、対象モジュール、エディションを整理します。

(2) リリースノートおよび互換性の確認
対象バージョンのリリースノートや移行ガイドを確認し、破壊的変更・必須メンテナンス・廃止機能などの影響範囲を把握します。

(3) カスタマイズ／ユーザモジュールの棚卸し
標準ファイルの上書き箇所、独自モジュール（immファイル）やクラス差分、module.xmlの依存関係を洗い出します。必要に応じて、ソースの再ビルド計画を立ててください。

(4) 依存ソフトウェアの確認
Javaバージョン、アプリケーションサーバ、データベース、外部ライブラリの対応状況を確認します。

(5) バックアップの取得
データベース（スキーマおよびデータ）、現行のWARファイル（WEB-INF配下）、静的ファイル（Webサーバ配下）、設定ファイル、カスタマイズ成果物をバックアップします。※本作業は必ず実施してください。

(6) テスト環境の準備
本番運用環境と同等の構成を持つテスト環境を用意し、事前に検証を実施します。検証を行わずに本番運用環境へ直接適用することは避けてください。ただし、緊急性の高いセキュリティパッチを適用する場合など、例外的に本番運用環境へ直接適用することがあります。

注意
  • カスタマイズによる不具合：標準ファイルを直接上書きしている場合、アップデートにより内容が上書きされたり、互換性が失われる場合があります。可能な限り拡張ポイントを利用し、カスタム差分は再ビルドして適用してください。
  • クラス競合：WEB-INF/classesとWEB-INF/libの読み込み順によって、クラスの競合が発生する場合があります。クラス配置や依存関係に注意してください。
  • モジュール依存関係の不整合：module.xmlの設定が不適切な場合、モジュールの適用順序や依存関係の不整合が発生する可能性があります。事前に設定内容を確認し、依存関係が正しく満たされていることを確認してください。
参考
コラム

intra-martのアップデートは、利用している製品やバージョンに応じて複数のパターンに分かれ、それぞれ手順が異なります。全体の流れやパターンの詳細については、「バージョンアップ、アップデートの手引き - 2. intra-mart Accel Platform でのバージョンアップ、アップデートの概要」を参照してください。

2. WARファイルの出力​

アップデートまたはパッチの適用対象に応じて、IM-JugglingでWARファイルを出力します。

(1) 古いリポジトリ情報の削除
IM-Jugglingを起動し、「設定」画面にある「モジュールリポジトリ」から「ローカルリポジトリ」の削除を実行します。処理中は、他の操作を行うことができません。

(2) モジュール情報の更新
IM-Jugglingでプロジェクトのモジュール情報を更新します。

  • アップデートの場合：対象バージョンのモジュールを選択し、既存プロジェクトのモジュール情報を変更
  • パッチ適用の場合：パッチを適用するモジュールを選択し、既存プロジェクトのモジュール情報を変更

(3) バージョン差異に伴う個別対応（アップデート時のみ）
アップデート元のバージョンによっては、バージョンごとに異なるメンテナンス作業が必要となります。特に複数バージョンをまたぐアップデートの場合は、各バージョンに対応する作業を順に実施する必要があります。

(4) IM-Jugglingへの取り込み
プロダクトリポジトリデータをIM-Jugglingに取り込みます。

(5) カスタムモジュールの対応
必要に応じて新バージョンで再ビルドを行い、immファイルの取り込みやWARファイルへの同梱方法を検討します。

(6) WARファイルの出力
IM-JugglingでWARファイルを出力します。出力されたWARファイルを次工程（デプロイ）で使用します。

注意

オフライン環境でのIM-Juggling利用：インターネット接続ができない環境では、事前にプロダクトリポジトリデータを取得しておく必要があります。取得にはライセンスキーが必要です。

参考
3. WARファイルの更新​

アプリケーションの差し替えを安全に行うため、既存環境を停止し、現行のWARファイルを退避させた上で、新しいWARファイルを配置します。

(1) サービスの停止
既存環境のアプリケーションサーバ（Resin、Tomcatなど）を停止し、必要に応じてWebサーバも停止します。

(2) 旧WARファイルのアンデプロイ
現行のWARファイルをアンデプロイします。ロールバックに備えて、旧WARファイルは保管しておいてください。

※ アップデートの場合は、必要に応じて以下の対応を実施してください。

  • 永続化されたセッション情報の削除
  • アプリケーションサーバ（Resin、Tomcatなど）の更新
  • その他のシステム要件の更新

(3) 新WARファイルのデプロイ
IM-Jugglingで生成した新しいWARファイルをデプロイします。

参考
4. テスト環境の初期化・反映​

各種設定の反映や環境初期化、キャッシュやバッチ処理などの後処理を実施し、システムを正常な動作状態に整えます。

(1) 静的ファイルの出力・再配置
Webサーバを利用している場合は、静的リソース（CSS, JavaScript, HTMLなど）を出力し、Webサーバのドキュメントルートへ配置します。

(2) テナント環境セットアップの実行
デプロイ後、テナント環境セットアップを実行し、データベースマイグレーションや設定の初期化を行います。テナント環境セットアップは、Webブラウザのセットアップ画面またはコマンドから実行できます。必要に応じて、テナント環境セットアップ時にサンプルデータを投入してください。

(3) メンテナンス処理の実行（アップデート時のみ）
必要に応じて、メンテナンス処理（キャッシュクリア、インデックス再作成、マイグレーションSQL実行、バッチ・ジョブの再登録など）を実施します。実施順序は、各製品のドキュメントに従ってください。

注意
  • Webサーバの静的ファイル不整合：古い静的ファイルが残っていると、画面崩れが発生することがあります。出力後は必ず差し替えおよびキャッシュクリアを行ってください。
  • Webサーバ経由のテナント環境セットアップ：Webサーバを経由してテナント環境セットアップを行う場合は、タイムアウト値に注意してください。Webサーバのタイムアウト設定値を変更するか、アプリケーションサーバ経由でのセットアップを実施することを推奨します。
  • サンプルデータ投入によるエラー発生：サンプルデータを投入してエラーが発生した場合、再実行するとデータベースの一意制約違反が発生する可能性があります。その場合は、一度アンインストールを実施した上で、再度セットアップを行ってください。
参考
5. テスト環境の確認​

テスト環境にアップデートやパッチ適用を反映した後、システムの動作に問題がないことを確認するため、以下のテストを実施します。

(1) 起動確認
アプリケーションの起動ログにエラーがないこと、および正常にWebブラウザ画面へアクセスできることを確認します。

(2) 機能確認（スモークテスト）
ログイン、主要業務フロー、ファイルアップロード、外部連携、バッチ実行などを実施し、基本機能が正常に動作することを確認します。

(3) カスタマイズの確認
独自モジュールやUIカスタマイズ、拡張ポイントが正しく動作することを確認します。必要に応じて、再ビルドや設定修正を行ってください。

(4) 性能・負荷・長時間テスト
必要に応じて、パフォーマンステストを実施し、クエリやバッチ処理の負荷状況を確認します。

(5) ログおよび監視の確認
アプリケーションおよびデータベースのログを一定期間監視し、異常が発生していないことを確認します。

注意

データベーススキーマの変更：バージョン差により、スキーマ変更（DDL）やマイグレーションSQLの適用が必要になる場合があります。必ずテスト環境で事前に検証してください。

6. 本番運用環境への適用​

テスト環境で問題がないことを確認した上で、本番運用環境へアップデートを適用します。

(1) 事前通知
切替時間帯（メンテナンスウィンドウ）および影響範囲（利用停止となる機能や対象ユーザなど）を整理し、関係者へ事前に通知します。

(2) 本番運用環境への反映
テスト環境で実施した一連の手順（バックアップ取得、WARデプロイ、テナントセットアップ、メンテナンス実行、動作確認）と同様の手順を、本番運用環境でも実施します。

7. ロールバック手順の準備​

アップデートに問題が発生した場合に備え、速やかに元の状態へ戻せるように、ロールバック手順を準備します。

(1) 復元手順の決定
即時にロールバックできるよう、旧WARファイルおよびデータベースのスナップショットからの復元手順を整理します。

(2) 手順のドキュメント化
旧WARファイルの再デプロイ、データベースのリストア、静的ファイルの復元、キャッシュクリア、関連サービスの再起動などの手順を文書化します。