Installation Managerで導入した場合
最近はあまり使われなくなりましたが，製品版のWebSphere Libertyは，IBM Installation Manager（以下IIM）を使用して導入することもできます。IIMは，従来型のWebSphere（WebSphere traditionalランタイム）や開発製品などの導入・更新に使用されていたツールです。
IIMは，最初の製品の導入だけでなく，運用中に定期的におこなわれるFixpack適用でも使用されます。IIMでは，自身で導入した製品のファイルの一覧を持っており，ユーザー作成の環境を壊さずに，製品のファイルだけを入れ替えることができるようになっています。IIMを使用して導入した場合は，普通にFixpackのレポジトリ・ファイルを入手し，IIMで指定した上で適用してください。
IIMは，このように高機能ではあるのですが，GUIでの操作もしくはレスポンスファイルの作成が必要で，更新作業にも時間がかかるなど，昨今のDevOpsなどのモダンな運用との相性は良くありません。そのため，昨今ではあまり使われなくなってきています。
Platform as Codeで導入した場合
Libertyでは，製品＋構成＋アプリケーションの導入が完了した環境を単一のZIPファイルやJARファイルにパッケージングすることができるようになっています。これにより，製品のFixpackレベルや構成も含めてソースとして管理し，Gitなどのバージョンコントロールシステムで管理できるようになります。アプリケーションのサーバーへのデプロイ作業など，従来のJava EEアプリケーションサーバーで手間も時間もかかっていた作業は必要なくなります。
ZIPを作成した場合は，入れ替え時には既存のWAS Liberty環境を全て消去し，新たにZIPファイルを展開して更新します。JARファイルの場合は，サーバー上のファイルを入れ替え，新しいJARファイルを実行します。
このような運用方法をとった場合，Fixpakの適用は，新しいZIP/JARファイルをビルドする，という作業になります。パッケージを作成する方法は何通りかあります。
Eclipseを使用して作成している場合
Eclipseには，複数のサーバーを定義することが可能です。現在使用しているバージョンのLibertyに加えて，更新先のバージョンのLibertyを作成してください。
(スクリーンショット追加予定)
Fixpack適用のためのパッケージは，新しいバージョンのServerのメニューからpackageを選択します。
(スクリーンショット追加予定)
Mavenを使用して作成している場合
Mavenを利用してパッケージを作成する場合，Libertyプラグインのconfigurationのなかで，<runtimeArtifact>で使用する製品のランタイムをバージョンつきで指定することが可能です。製品でどのようなartifactIdが利用でき，どのようなバージョンが提供されているかは，Maven Repositoryを検索して調べます。
<plugin>
<groupId>io.openliberty.tools</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>3.6.1</version>
<configuration>
<serverName>myAppServer</serverName>
<runtimeArtifact>
<groupId>com.ibm.websphere.appserver.runtime</groupId>
<artifactId>wlp-webProfile7</artifactId>
<version>22.0.0.6</version>
<runtimeArtifact>
<include>minify</include>
</configuration>
</plugin>
この場合は，Fixpackの適用は<version>の行を書き換えて，パッケージを再ビルドします。
Dockerfileでコンテナイメージを作成している場合
IBMからDocker Hubなどで提供されているLibertyランタイムのイメージは，バージョンごとにタグをつけられて提供されています。Dockerfileを記述するときには，バージョンなしのlatestをさすタグではなく，バージョン番号つきのタグを指定します。
FROM docker.io/ibmcom/websphere-liberty:22.0.0.3-kernel-java11-openj9-ubi
この場合のFixpack適用は，このFROM行のバージョン番号を書き換えて，コンテナイメージを再ビルドすることでおこないます。
アーカイブファイルを展開して導入した場合
配布されているWebSphere Libertyのアーカイブを展開すると，以下のようなディレクトリが作成されます（etcは，必要ならば利用者側で作成します）。
wlp
├─ bin
├─ clients
├─ dev
├─ etc
├─ lafile
├─ lib
├─ temlates
└─ usr
このうち，利用者側でファイルを作成したり編集したりすることができるのは，usrとetcディレクトリだけです。そのほかのディレクトリのファイルは製品から提供されるものをそのまま使用する必要があります。
Fixpackの適用は，このusrとetcの二つのディレクトリのファイルを適用前後で保存し，そのほかのディレクトリを全て新しいファイルで入れ替えることでおこないます。方法はいくつか考えられます。
現在のディレクトリをリネームして保存する
以下のような手順でおこないます。
- wlpディレクトリを別の名前（wlp_old.21.0.0.3など）にリネームして待避
- 新しいFixpackレベルのアーカイブを展開して，wlpディレクトリを再作成
- 旧環境のusr/etcディレクトリを，ディレクトリ単位で新環境にコピー
この場合，新環境で万が一問題が起こった場合は，新環境をリネームして待避し，旧環境をリネームしてwlpに戻します。新環境でFixpack適用後におこなった変更などは旧環境には反映されていないことに注意する必要があります。
usrディレクトリを，wlpの導入ディレクトリ外におく
デフォルトでは，ユーザー構成が格納されている場所は，製品導入ディレクトリ（wlp）の直下のusrディレクトリが使われます。このディレクトリは，環境変数WLP_USER_DIRで別の場所を指定することができます。
そのため，ユーザー構成を格納するディレクトリを製品ディレクトリとは別に作成し，新旧の環境から環境変数で参照して使用することができます。この場合の環境変数の指定場所として，etcディレクトリのserver.envが使用できます。
/opt/IBM/WebSphere
├─ wlp -> ./22.0.0.6/wlp
├─ 21.0.0.3
│ └─ wlp
│ └─ etc
│ └─ server.env
├─ 22.0.0.6
│ └─ wlp
│ └─ etc
│ └─ server.env
└─ wlp_usr
Fixpackレベルでディレクトリを作成して，その中にLibertyランタイムをアーカイブから展開します。そのなかで，使用するバージョンのwlpディレクトリをシンボリック・リンクで指定しておきます。各バージョンのwlpディレクトリにはetcディレクトリを作成し，server.envファイルを配置して，共通のユーザーディレクトリを指し示すようにします。
WLP_USER_DIR=/opt/IBM/WebSphere/wlp_usr
このようにすると，シンボリック・リンクの付け替えでバージョンの切り替え・切り戻しができます。切り戻しをした場合には，ユーザーディレクトリに格納されているパーシスタント・キャッシュが不整合を起こすため，切り戻して最初の一回だけは，serverコマンドに--cleanオプションを指定してLibertyランタイムを起動するようにします。