heroku上の既存のwordpressサイトをPipelineにする(2017/09/05追記)

heroku上の既存のwordpressサイトをPipelineにする(2017/09/05追記)

wordpressのサイトをherokuで運用しています。

git管理されたファイル以外は消えてしまうというherokuの特性上、アップデートやプラグインはローカルで解凍して、commit、pushしています。画像はCloudinaryのadd-onです。
デプロイは、githubではなくheroku gitに直接です。

しかし、合わないプラグインを入れてサイトが落ちることが数度。
wordpress本体のアップデートはとにかく面倒くさい上に、落ちたときに戻す手間も考えると後回しになる。セキュリティ上よろしくないけどやりたくない。新しい機能やプラグインも使えないけどやりたくない。
特にマルチサイトになると、エラーを起こすと全てのサイトが落ちます。Eneleaksはエネルギー情報サイトとして多くの方に読んでいただいていますし、kohuku Sengawaの営業時間やメニューを知りたい方がサイトに繋がらなかったら来てもらえないかも知れませんし、他にも予告なしに繋がらなくなることによるお客様への影響や機会損失を意識するサイトが、まとめて落ちるのです。

そろそろ、テスト環境がほしい。テストと本番で同じ作業を繰り返したくないから、ソースコードはテストからまるごと本番にコピーしたい。

そこで、パイプラインです。きいたところによると。

pipeline

これしかない。

ちなみに、やってみたら、REVIEW APPSからのステージングへの反映は、GitHubでPull Requestをマージしないとできませんでした。ワンクリックできませんでした。
あと、よくよく考えればわかることなのですが、wordpressだとREVIEW APPSはポンコツです。残念ですが。理由は後述します。

 

1 Pipelineを作って今のAppをProduction(本番)にする

「heroku」の管理画面から、wordpressapp(※本番App名)の詳細を開きます。

Deployタブを開くと、上の方に「New Pipeline…」というボタンがあるので、クリック。
Pipeline Nameにわかりやすい物を入れて、Create Pipeline。
以上。

 

2 ステージング環境にするAppを作る

PCで、PowerShellで、ローカルのAppのソースがあるフォルダに移動。
cd c:\heroku\wordpressapp(※本番App名)

※ windowsなのでパワーシェルを使っていますが、コマンドプロンプトでもBashでも同じです。

git remote -v
で登録されているリモートを確認すると、以下の二行だけが出てくる状態。
heroku https://git.heroku.com/wordpressapp.git (fetch)
heroku https://git.heroku.com/wordpressapp.git (push)

内容をコピーしたAppを作ります。
heroku fork –from wordpressapp –to wordpressapp-staging(※新しいステージングApp)

新しいアプリができて、プラグインも同じプランで丸ごと追加されます。
不要なものや、ステージングでは廉価や無料の範囲で足りるものは、herokuの管理画面から設定を変更。

postgreSQLだとデータベースの中身もコピーされると聞いたのですが、ClearDBのMySQLなので、この時点ではデータベースは空です。
しかし、実行してWPのサイトを作成しないでください。先にドメインを登録します。

 

3 テスト用のURLを登録する

herokuの管理画面から、作りたてのwordpressapp-staging(※ステージングApp)の詳細を開く。

Settingsタブを開き、中程の「Add Domain」に、「test.wordpressapp.com」などとテスト用のURLを追加します。
wordpressapp.comが、本番のURLだと思ってください。
わかりやすくサブドメインにしました。

DNSは、PointDNSアドオンを使っています。
herokuの本番App(wordpressapp)の詳細画面から、PointDNSの画面を開きます。
wordpressapp.comを選択し、レコードを追加

レコードタイプ:CNAME
名前:test(.wordpressapp.com.)
仕向先:wordpressapp-staging.herokuapp.com.(※ステージングApp)

 

4 Githubにリポジトリを作ってファイルをコピー

Githubのサイトを開いてログインして、右の方の「New Repository」ボタンをクリック。

Repository name : wordpressapppipeline(※てきとう)
Initialize this repository with a README : チェックなし
Add .gitignore : none
Add a license : none

この設定で作ったら、できあがった画面にずらずら出てくるテキストから

https://github.com/アカウント/wordpressapppipeline.git ← これをコピペ。

作ったリポジトリのトップ画面の Codeタブの、「Clone or download」ボタンからでも。

 

PCで、PowerShellでソースコードのあるディレクトリを開いた状態。
そこに、Githubをリモートに追加します。

git remote add origin https://github.com/アカウント/wordpressapppipeline.git

git remote -v
で登録されているリモートを確認すると、originという名前で追加されています。
heroku https://git.heroku.com/wordpressapp.git (fetch)
heroku https://git.heroku.com/wordpressapp.git (push)
origin https://github.com/qoomk/ohspipetest.git (fetch)
origin https://github.com/qoomk/ohspipetest.git (push)

これまでのherokuのmasterブランチではなく、新たに追加したGithub用のoriginのmasterブランチにファイルをpushすることで、ファイルがGithubにコピーされます。
git push origin master

 

5 Pipelineを完成させる

herokuのApp一覧に現れたPipelineの全体像を開きます。

まだ、PRODUCTIONにこれまでの本番が登録されているだけです。

上部に「Connect this pipeline to GitHub to 略」と書かれているところの「Connect to Github」ボタンを押します。
アカウントを連携し、4で作ったリポジトリを検索し、登録します。

STAGINGにwordpressapp-staging(※2で作ったステージングApp)を登録して、Appの詳細を開きます。
Deployタブを開くと、Githubが自動的に繋がっています。
下部の「Enable Automatic Deploys」ボタンを押して有効にします。Githubのmasterブランチが更新されると自動的にここに反映されるようになります。

 git remote rm heroku でherokuとPCの接続を切ります。

Pipelineの全体像の左、REVIEW APPを登録します。
後述しますがwordpressだとほぼ使えないので必要ないのですが、一応、書いておきます。
「Enable Review App…」ボタンを押して、手順に従ってSTAGINGに登録した方のAppを選んで作成画面、次はそのまま、次は「Create new review apps for new pull requests automatically」にチェックをいれて進むと、レビューアプリを作る設定ファイル「app.json」がGithubのmasterブランチに自動的に作成されます。

忘れないうちにPCのファイルをGithubの方と同期させて、app.jsonを取得しておきます。
git git pull origin master ですが、しばらく手癖でherokuって打ってしまう。

 

6 ステージング用にデータベースを用意する

本番用のデータベースを、テーブルも全て、ステージング用のデータベースにコピーします。
例として、phpMyAdminのエクスポート&インポート機能を使うときはこのように。

※ 下に、運用時に本番のDBをステージングにコピーするときに行っている、おすすめの方法を追記しました。環境構築時にも、この方が楽なはずです。

本番DB > エクスポート(テーブルでなくDBを選んだ状態で)

・エクスポート方法 : 詳細
・テーブル : 全選択(※)
・出力をファイルに保存を選択したまま、他のオプションもそのまま
・フォーマット : SQL
・フォーマット特有のオプション : コメントの表示そのままオン、構造とデータを選択
・生成オプション : DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT コマンドを追加するにチェック。その下も全てチェックしたまま
・Data creation options : そのまま
・エンコーディングへの変換 : なしのまま

 

ステージングDB > インポート

・インポートするファイル : アップロードファイルを選択し、上で作成、ダウンロードしたSQLファイルを指定

※ インポートできるファイルの容量を超えてしまうときは、ファイルに保存ではなくサーバーに書き出しで対応しています。エラーで止まるときは、テーブルをいくつかに分けています。

取り込まれたら、ステージングDBのwp_optionsからURLを書き換えます。
サイトタイトルも、テストだとわかるものに変えておくとわかりやすいです。

マルチサイトだと、サイトの数だけwp_●●_optionsのURLとタイトルを変えることになります。wp_domain_mapping(プラグインを用いてマルチドメインで運用している場合)、wp_site、wp_blogsのURLも書き換えます。

herokuwp

この時点では、ステージングから繋がるDBはまだ本番のものです。

/wp-config.php を書き換えます。
ステージングと本番で同じソースを使うために、testで始まる(※2で登場しているステージング用URL)ホスト名でアクセスしているときは、ステージングDBを見るようにします。

マルチサイトのときはドメイン名もここで。

 

※ データベースが大きくて画面からインポート&エクスポートしきれないときに限らず、これがおすすめ

こちらを真似しました。テーブルロックしないオプションをつけて、ファイル名を短くしたくらいです。
http://kayakuguri.github.io/blog/2015/09/10/mysql-postgres-import-export/

mysqlのコマンドが実行できて、容量に余裕のある環境で、コマンドを実行できる状態になって。
ちなみに私は、さくらインターネットのVPSでやりました。

確実に終わる。速い。楽。

change-wpurl.sqlは、本番用からテスト用へのURL書き換えのSQL文です。
あらかじめサーバーに置いておきます。実際にはこんな内容です。

 

7 アクセス設定を整える

herokuappのURLでアクセスされたときに独自ドメインに転送する、テスト環境のときはベーシック認証をかける、等の設定をします。.htaccessに追記。

<If “%{HTTP_HOST} == ‘test.wordpressapp.com'”>ここを、test.ではじまるときは全て、のような汎用的な書き方にする方法を知りたいです。
LocationやFileだと正規表現が使えるのですが、あいにくホスト名でしか判別できないので。

今現在、マルチサイトだと<If”%{HTTP_HOST} == ‘test.wordpressapp.com’ || %{HTTP_HOST} == ‘test.eneleaks.com’ || %{HTTP_HOST} == ‘test.kohuku.jp’ || … “>という書き方です。

 

8 6、7で編集した設定ファイルをGithubの方にpushする

git add .
git commit -m “コメント”

ここまでは今までと同じですが、次が、heroku宛てではなくなります。

git push origin master

そして、Pipelineの全容画面を見ると、STAGINGのところが勝手に変更を察知してじわじわ動きます。

 

9 本番にアップロード

STAGINGのAppをブラウザで開くと、ベーシック認証を求められ、テストの目印をつけたタイトルのサイトが開きます。

正しい動作を確認したので、「Promote to Production」ボタンを押します。本番にファイルが丸ごとコピーされました。

本番では認証なしで、本番用のデータベースに繋がります。

 

※ REVIEW APPSがwordpressだとほぼ使えない理由

ブランチを分けてファイルを編集してPull Requestを送るとたしかにレビュー用のサイトがPipelineの画面に出現したのですが、URLがwordpressapp-staging-pr-●●.herokuapp.com等になっています。ステージングとも本番ともURLが違うのは当たり前ではあるのですが。
wordpressは、DBに登録してあるURL以外で開くと、スタイルシートが正しく読み込まれなくてガタガタになります。なので、PHPがエラーを起こさないことだけは確認できますが、REVIEWでできるのはwordpressだとそれくらいになってしまいます。