アプリケーションのアップグレード パーマリンク to " アプリケーションのアップグレード"

サマリー パーマリンク to "サマリー"

  1. 選択1 - 自動アップグレード
  2. 選択2 - 手動アップグレード

選択1 - 自動アップグレード パーマリンク to "選択1 - 自動アップグレード"

JHipsterの新しいバージョンがリリースされると、JHipsterアップグレードサブジェネレータは、変更を消去することなく、既存のアプリケーションを新しいバージョンにアップグレードするのを手助けします。

これは、以下の場合に役立ちます。

  • 既存のアプリケーションに最新のJHipsterの機能を搭載させる
  • 重要なバグ修正またはセキュリティ更新がある場合に変更を取得する
  • コードベースに加えた変更を保持し、新しく生成されたコードとマージする

アップグレードを行う前にこのページをよく読んで、アップグレードプロセスがどのように機能するかを理解してください

要件 パーマリンク to "要件"

このサブジェネレータを動作させるには、http://git-scm.comからgitをインストールする必要があります。

アップグレードサブジェネレータの実行 パーマリンク to "アップグレードサブジェネレータの実行"

アプリケーションのルートディレクトリに移動します。

cd myapplication/

アプリケーションをアップグレードするには、次のように入力します。

npx jhipster upgrade

渡すことができるオプションは以下のとおりです。

  • --verbose - アップグレードプロセスの各ステップを詳細に記録します。
  • --target-version 6.6.0 - 最新リリースではなく、ターゲットバージョンのJHipsterにアップグレードします。プロジェクトが数個のバージョン分遅れている場合に便利です。
  • --target-blueprint-versions [email protected],[email protected] - 各Blueprintの最新リリースではなく、ターゲットのBlueprintのバージョンにアップグレードします。ただし、Blueprintのターゲットバージョンは、ターゲットのJHipsterバージョンと互換性がある必要があります。
  • --force - 新しいJHipsterバージョンが利用できない場合でも、アップグレードサブジェネレータを実行します。
  • --skip-checks - プロジェクトの再生成時のチェックを無効にします。
  • --skip-install - アップグレードプロセス中の依存関係のインストールをスキップします。
  • --silent - 生成プロセスの出力を非表示にします。

複数回アップグレードする場合は、最初に次のようにJHipsterツリーをアップグレードすることを検討できます。

git checkout jhipster_upgrade
git checkout --patch master .yo-rc.json
git checkout --patch master .jhipster
git commit -a
git push --set-upstream origin jhipster_upgrade
git checkout master

上記の手順を実行すると、jhipster_upgradeツリーが最新の変更内容でアップグレードされるため、JHipsterはアップグレード中にそのツリーを利用できます。たとえば、モデルを変更した場合などです。

アップグレードプロセスをグラフィカルに表示 パーマリンク to "アップグレードプロセスをグラフィカルに表示"

以下にアップグレードプロセスの動作を図で示します(テキストによる説明については、次のセクションを参照してください)。

GitGraph

(イメージはJSFiddleより(日本語バージョンはこちら))

上のグラフでは正しく表示されていませんが、jhipster_upgradeブランチはプロジェクトで孤立して作成されることに注意してください。

アップグレードプロセスの段階的な説明 パーマリンク to "アップグレードプロセスの段階的な説明"

JHipsterアップグレードサブジェネレータによって処理される手順は以下のとおりです。

  1. 新しいバージョンのJHipsterが利用可能かどうかをチェックします(--forceを使用している場合は適用されません)。
  2. アプリケーションがすでにgitリポジトリとして初期化されているかどうかをチェックします。そうでない場合は、JHipsterがリポジトリを初期化し、現在のコードベースをmasterブランチにコミットします。
  3. リポジトリにコミットされていないローカル変更がないことを確認します。コミットされていない変更が見つかった場合、プロセスは終了します。
  4. jhipster_upgradeブランチが存在するかどうかをチェックします。存在しない場合は、ブランチが作成されます。このステップの詳細については、「最初のアップグレードの具体的な手順」のセクションを参照してください。
  5. jhipster_upgradeブランチをチェックアウトします。
  6. JHipsterを利用可能な最新バージョンにグローバルにアップグレードします。
  7. 現在のプロジェクトフォルダをクリーンアップします。
  8. jhipster --forceコマンドを使用してアプリケーションを再生成します。
  9. 生成されたコードをjhipster_upgradeブランチにコミットします。
  10. npx jhipster_upgradeコマンドが起動された元のブランチにjhipster_upgradeブランチをマージして戻します。
  11. ここで、マージ競合がある場合は、それを解決する必要があります。

おめでとうございます。アプリケーションが最新バージョンのJHipsterにアップグレードされました。

最初のアップグレードの具体的な手順 パーマリンク to "最初のアップグレードの具体的な手順"

JHipsterアップグレードサブジェネレータの最初の実行では、すべての変更が消去されないようにするため、いくつかの追加手順が実行されます。

  1. jhipster_upgradeブランチが孤立して作成されます(親がありません)。
  2. アプリケーション全体が生成されます(現在のJHipsterバージョンを使用)。
  3. ブロック・マージ(訳注:Oursマージストラテジでのマージのようです)コミットがmasterブランチで行われます。masterブランチのコードベースは変更されません。これは、masterのHEADが現在のJHipsterバージョンで最新であることをGitに記録するための実用的な方法です。

アドバイス パーマリンク to "アドバイス"

  • jhipster_upgradeブランチでは何もコミットしないでください。このブランチはJHipsterアップグレードサブジェネレータ専用です。サブジェネレータが実行されるたびに、新しいコミットが作成されます。

  • 非常に古いバージョン(5.0.0から最新など)からアップデートする場合は、各マイナー/パッチバージョンの間に徐々にアップデートし、アプリケーションが期待どおりに動作することを確認するためのテストを実行することをお勧めします。

  • 更新プロセスを容易にし、マージ競合の量を減らすような方法でアプリケーションを設計することに関して、JHipsterコミュニティからいくつかの有用なアプローチがあります。JHipsterのSide-by-Sideアプローチの使用をお勧めします。

選択2 - 手動アップグレード パーマリンク to "選択2 - 手動アップグレード"

手動アップグレードの場合は、まず次のコマンドを使用してJHipsterのバージョンをアップグレードします。

npm install -g generator-jhipster

プロジェクトのnode_modulesフォルダを削除し、次のコマンドを実行します。

jhipster

次のコマンドの実行で、プロジェクトとそのすべてのエンティティの更新もできます。

jhipster --force

また、エンティティサブジェネレータを再度実行して、エンティティの1つずつの更新もできます。たとえば、エンティティの名前が Foo の場合は次のとおりです。

jhipster entity Foo

名前を変更したファイルに関するヒント パーマリンク to "名前を変更したファイルに関するヒント"

ジェネレータ内でファイルの名前が変更されることがあります。Gitの名前変更の検出結果を確認したい場合は、git addgit add . で全てをステージングへ)を実行し、その後の変更をお気に入りのGitクライアントで確認できます。

多くのファイルの名前が変更された場合、Gitの名前変更の検出が期待通りに動作するように、Git設定のdiff.renameLimitを増やしたい場合があります。例えば、git config --replace-all diff.renameLimit 10000です。

デフォルトでは、Gitの名前変更の検出は50%の類似性しきい値を使用します。名前が変更されたファイルの類似度を低くするには、Gitコマンドでオプション--find-renames=<n>を使用できます。たとえば、git diff --staged --find-renames=30です。

独自の変更を表示 パーマリンク to "独自の変更を表示"

プロジェクトの生成後に行った変更を確認するには、次の手順に従います。

git cloneを使用して、プロジェクトを新しいフォルダにクローンします。

.git.jhipsterおよび.yo-rc.jsonを除くすべてのファイルとフォルダをクローンプロジェクトから削除します。

前回プロジェクトを生成したときに使用したJHipsterのバージョンを調べます。プロジェクトルートフォルダの.yo-rc.jsonを見て、jhipsterVersionの値を調べます。

前回プロジェクトを生成したときに使用したバージョンのJHipsterをインストールします。

npm install -g generator-jhipster@前回使用したJHipsterのバージョン

プロジェクトを再生成します。

jhipster --force --skip-install

git diffを使用すると、すべての変更が打ち消し(revert)された状態として確認できます。すべての変更を追加(add)された状態として確認したい場合は、すべてをGitにコミットしてから、前回のコミットを打ち消しします。

JHipsterの変更点を参照 パーマリンク to "JHipsterの変更点を参照"

JHipsterによる変更を確認したい場合は、以下の手順に従ってください。

前回プロジェクトの生成に使用したJHipsterバージョンでプロジェクトを生成します。

  • 新しいフォルダを作成します。
  • プロジェクト.yo-rc.jsonファイルと.jhipsterフォルダをこの新しいフォルダにコピーします。
  • 前回プロジェクトを生成したときに使用したJHipsterのバージョンを調べます。.yo-rc.jsonを見て、jhipsterVersionの値を調べます。
  • 前回プロジェクトの生成に使用したJHipsterのバージョンをインストールします:npm install-g generator-jhipster@前回使用したJHipsterのバージョン
  • 作成したフォルダで、次のコマンドを実行します:jhipster --skip-install

最新のJHipsterでプロジェクトを生成します。

  • 新しいフォルダを作成します。
  • プロジェクト.yo-rc.jsonファイルと.jhipsterフォルダをこの新しいフォルダにコピーします。
  • 最新のJHipsterバージョンをインストールします:npm install -g generator-jhipster
  • 作成したフォルダで、次のコマンドを実行します:jhipster --skip-install

これらの2つのフォルダをお好きなファイルおよびフォルダ比較ツールと比較して、JHipsterによって行われた変更を確認します。