Magentoをアップデートするには | さくらのナレッジ

今回はMagentoをアップデートする方法をご紹介しましょう。
Magentoは概ね2〜3ヶ月に1回マイナーバージョンアップがあり、1年ごとにメジャーバージョンアップが行われます。

最初にMagentoのメンテナンス期限を知っておこう
Magentoをアップデートする前に
検証環境でのアップデートと調整作業の実施
メンテナンス実施の告知とアップデートの本番適用
終わりに

最初にMagentoのメンテナンス期限を知っておこう

Magentoのメンテナンス期限は、「各バージョンの初回リリースから原則2年間」と定められています。（あくまで原則なので、大人の事情によって期間が変わることがあります）

厳密には無料版のMagento Open Sourceと有償版のMagento Commerceで異なりますが、公表されているMagento Commerceでは次の表のとおりとなっています。（Magento公式サイトより 2018年3月現在）

バージョン番号	リリース月	サポート終了月
Enterprise Edition 1.9	2010/07	2012/07
Enterprise Edition 1.10	2011/02	2013/02
Enterprise Edition 1.11	2011/08	2013/08
Enterprise Edition 1.12	2012/04	2014/04
Enterprise Edition 1.13	2013/10	2020/06
Enterprise Edition 1.14	2014/06	2020/06
Enterprise Edition 2.0	2015/11	2018/03
Enterprise Edition 2.1	2016/06	2019/06
Magento Commerce 2.2	2017/09	2019/09

この表を元にすると、

2.0系は2018年3月でサポート終了
2.1系も2019年6月にはサポート終了

となります。これから新規に構築するのであれば、2.2系をベースにするのが最もサポート期限が長く取れるので、無難でしょう。

Magentoをアップデートする前に

Magentoに限った話ではありませんが、アップデートを行う前には準備が必要です。例えば以下の準備をしておきましょう。

アップデート先のバージョンに対応したテーマ・エクステンションの入手
アップデート後の挙動を確認するための環境の用意とテスト
メンテナンス実施の告知
ソース一式とデータベースのバックアップ

対応したテーマ・エクステンションの入手

Magentoのマイナーバージョンアップでもメジャーバージョンアップでも可能な限り最新版のテーマやエクステンションを入手しましょう。概して新しいバージョンではそれ以前のバージョンにあった不具合が解消されていることが多く、また新しい機能が追加されていることもよくあります。特にMagentoのメジャーバージョンアップ（例えば2.1から2.2へ）を行う場合には、テーマやエクステンションがアップデート先のバージョンに対応していることが不可欠です。ですからまず最初にアップデート先のバージョンに対応したものを入手することを心がけてください。

無償のエクステンションの場合は比較的簡単に新しいバージョンを手に入れられる可能性が高いですが、有償のエクステンションの場合は開発元の定めるメンテナンスやサポート規約に依存します。場合によっては新しいバージョンを買い直さなければならない可能性もありますし、運良くサポート期間内であれば対応バージョンが提供される可能性もあります。

例えば弊社の場合ですが、Magento2系用のエクステンションは以下のようにサポート期間を定めています。

購入日を起点として標準180日の無償アップデートとサポート。
購入時に延長サポートを選択した場合は、対象期間を360日に延長。

いずれにしてもアップデート先バージョンに対応したものを手に入れることを最初に行ってください。

アップデート後の挙動を確認するための環境の用意

面倒くさいかもしれませんが、アップデートを行う前に、検証用の環境を用意しましょう。いきなり本番でアップデートを行うのは大変危険なので、壊れてもかまわない検証環境で実験をするのが無難です。

データベースに対する変更に注意

Magentoのアップデートに限らず、大抵のソフトウエアのアップデートは広範囲に渡る変更が行われます。プログラムだけの変更であればまだ幸せな方で、データベースに対する大規模な変更が生じることがありえます。

運用中のサイトの場合、様々なデータが日々溜まっていきます。データベースに大規模な変更が生じる場合、変更の適用が終わるまでに要する時間がどの程度なのかは予想が難しいことが多々あります。検証環境で、本番環境のバックアップデータベースなどを用いて事前に検証することができれば、作業完了までの時間の目安をたてることができます。

検証環境でのアップデートと調整作業の実施

Magentoのアップデートを行う場合、一番オーソドックスな方法はcomposerを使う方法ではないかと思います。

Magentoのソースツリーをみると、一番上の階層にcomposer.jsonというファイルがあります。このファイルにはMagentoを構成するモジュールのバージョンや依存関係が定義されています。

アップデートの前に

例えばMagento本体のバージョン指定は次のように書かれています。

{
    "name": "magento/project-community-edition",
    "description": "eCommerce Platform for Growth (Community Edition)",
    "type": "project",
    "version": "2.2.3",
    "license": [
        "OSL-3.0",
        "AFL-3.0"
    ],
    "require": {
        "magento/product-community-edition": "2.2.3",
(以下略)
    }
(以下略)
}

Magento本体のアップデートを行う場合は、"magento/product-community-edition"の右側にある数字をアップデート先のバージョン番号に変更して保存します。その後、composer updateを実行するとMagento公式から指定されたバージョンに関係するモジュールをダウンロードして置き換えてくれます。

composer update時の注意

composer update を行うと、vendorディレクトリ下はcomposer.lockの内容に基づいて更新されます。composer.lockはcomposer.jsonに定義されたモジュール同士の依存関係を整理した結果で生成されるファイルです。もし、今利用しているよりも新しいバージョンのモジュールが利用できる場合、composerはそのバージョンでvendor下に配置されているモジュールを更新します。この時、何かしら独自の改変を加えていると、そのファイルはcomposerによって置換されてしまいます。

また、composer update時に、アップデート後のMagentoバージョンに適合しないモジュールがある場合は、処理が止まります。アップデート後のMagentoに適合するバージョン番号を調べてcomposer.jsonの定義を修正するなどの作業が必要です。

composer update後に行うこと

composer updateが無事に完了すると、Magentoを構成するファイルはアップデート後のバージョンに適合したものにすべて変わります。アップデート作業はまだ終わりではないので、引き続き作業を行いましょう。

composer updateの後は、以下の作業が必要になります。

追加されたモジュールの有効化（存在する場合）
コンパイル処理の実行
静的ファイルの生成
データベース定義などの更新

追加されたモジュールの有効化

この作業はMagentoのエクステンションを追加する場合と同じです。アップデートと同時に新しいモジュールが追加されることがよくあります。

php bin/magento setup:module:enable エクステンション名

を実行すると、モジュールを有効にできます。

コンパイル処理の実行

次に、コンパイル処理を行います。Magentoがdeveloperモードで動いている場合はやらなくても構いませんが、本番運用時はproductionモードが推奨されています。エクステンションによってはコンパイル処理が通らないようなものが時折存在するので、きちんと確認しておくと良いでしょう。

php bin/magento setup:di:compile

を実行すると、コンパイル処理を行います。

エラーが出た場合は、どのエクステンションに問題があるかを根気よく調べる必要があります。自社製でないものについては、開発者に修正を依頼してください。

静的ファイルの生成

コンパイルが無事に終わったら、次は静的ファイルの生成です。

php bin/magento setup:static-content:deploy 言語1 言語2 (以下略)

を実行することで、pub/staticディレクトリ下に静的ファイルが生成されます。これもdeveloperモードでは必須ではありませんが、JavaScriptやCSSファイルをminifyするなどした場合には不具合が起きやすいので、minifyを有効にして動作検証することを忘れないでください。

データベース定義などの更新

最後にデータベース定義などを更新します。

php bin/magento setup:upgrade

を実行すると、データベースの定義などを更新します。テーブルの列定義や制約が大きく変わるような場合、この処理に非常に長い時間を要することがあります。

動作チェックとカスタマイズ箇所の調整

ここまで無事にこれたら、いよいよ動作チェックとカスタマイズ箇所の調整です。完全に標準のままでMagentoを使っているようなケースは非常に珍しいと思いますので、殆どのサイトはここからが本当に大変な段階に入ります。

デザイン要件に合わせて調整したテーマや、自社用に独自開発したモジュールというのはMagentoの互換性チェックの適用を受けません。アップデートによる変更内容を考慮しつつ、サイトに合わせた調整を行う必要があります。

多くのサイトではこのステップでかなりの時間と手間を要します。テストの自動化などを検討するのも手ですね。

メンテナンス実施の告知とアップデートの本番適用

検証環境でここまでの流れが全て確認でき、問題がないと判断できたら、いよいよ本番反映の準備です。稼働中のサイトに大規模な更新を行うのですから、できれば事前にメンテナンスの告知を出しましょう。

メンテナンスモードの有効化

告知した時間になったら、Magentoをメンテナンスモードに切り替えます。

php bin/magento maintenance:enable

というようにコマンドを実行すると、メンテナンスモードを有効にできます。もし、特定のIPアドレスからだけサイトの閲覧を許したい場合は、

php bin/magento maintenance:allow-ips IPアドレス

を実行することで、許可IPを設定できます。

ソースコード一式とデータベースのバックアップ

アップデートを実施する前には、必ずソースコード一式とデータベースのバックアップを取りましょう。最悪の事態になったときでもバックアップさえ取っておけば、アップデート前の状態に戻すことができます。

もちろん、Gitなどのリビジョン管理システムを使ってより効率的な管理をするほうが望ましいですが、「リビジョン管理？」という方もプログラマー以外の方には多いと思いますので、ここではあえて掘り下げないことにします。

とにかく、アップデートを適用する前にはバックアップを取りましょう。バックアップを取らずにアップデートを行い、万一トラブルが起きてしまった際のアップデート前バージョンへの巻き戻しはかなり大変な作業です。

ソースコードの反映と、アップデート関連コマンドの実行

バックアップが問題なく採取できたら、新しいバージョンで調整ができているソースコード一式を本番サーバーに反映します。ファイルアップロードツールで頑張ってアップロードしても良いですし、zipなどで固めてアップロードした後にサーバー上で展開してからコピーしても構いません。とにかくサーバーに新しいバージョンのソースコードを反映しましょう。

その後は、検証環境上でアップデートを行う際に使用した4種類のコマンドを実行し、アップデートを適用します。

メンテナンスモードを終了してアップデートを完了する

すべてが無事に完了し、関係者チェックが終わったら、メンテナンスモードを終了させます。

php bin/magento maintenance:disable

これでMagentoが新しいバージョンになりました。

終わりに

駆け足でMagentoのアップデートに関する手順をご紹介しました。「なんて面倒くさいんだ」と思われた方も多いと思います。私も最初同じ感覚でした。ところが何度かアップデートをしていくと、これはこれで合理的なのではないかと思うようになってきました。

最新のMagento2.2系では、Pipeline Deploymentという概念が導入されています。バージョンアップだけでなく、単なるテンプレート修正であっても、Magentoの場合は所定の手順を踏まないと反映ができない作りになっています。Pipeline Deploymentはひとつの本番反映に関する概念と手順の例ですが、様々なデプロイツールを用いることで、ややこしい手順に悩まされなくても済むようにできます。