Post on 22-Jul-2015
Git 管理のパターン:テーマ
wordpress/wp-content/themes/theme/wordpress/wp-content/themes/theme/.gitwordpress/wp-content/themes/theme/.gitignore
wordpress/wp-content/themes/theme/wordpress/wp-content/themes/theme/.gitwordpress/wp-content/themes/theme/.gitignore
テーマディレクトリだけを管理するパターン
Git 管理のパターン:テーマ.gitignore 例
*.diff*.err*.orig*.log*.rej*.swo*.swp*.zip*.vi*~*.sass-cache*.seed*.csv*.dat*.out*.pid*.gz
よくある拡張子
.DS_Store
._*Thumbs.db.cache.project.settings.tmproj.esprojnbproject.sublime-project.sublime-workspace.csscomb.json
環境依存ファイル
.hg
.svn
.CVS
.idea
.ssh
.gruntnode_modulesdistlib-covlcov.infopidslogsresultsbuild
よくあるフォルダ
Git 管理のパターン:テーマ
メリット
• お手軽• 管理が簡単• 運営も簡単• パブリックに公開し易い
デメリット
• コア等ロールバック時の手間• プラグインを戻す時も同様• コアやプラグインが環境毎にずれる• チーム間でもバラバラ
Git 管理のパターン:コア
wordpress/wordpress/.gitwordpress/.gitignore
wordpress/wordpress/.gitwordpress/.gitignore
WordPress コアをまるごと管理するパターン
*.log.htaccesssitemap.xmlsitemap.xml.gzwp-config.phpwp-content/advanced-cache.phpwp-content/backup-db/wp-content/backups/wp-content/blogs.dir/wp-content/cache/wp-content/upgrade/wp-content/uploads/wp-content/wp-cache-config.php
*.log.htaccesssitemap.xmlsitemap.xml.gzwp-config.phpwp-content/advanced-cache.phpwp-content/backup-db/wp-content/backups/wp-content/blogs.dir/wp-content/cache/wp-content/upgrade/wp-content/uploads/wp-content/wp-cache-config.php
テーマのパターン +
.gitignore 例
Git 管理のパターン:コア
環境毎に内容を分ける為DB 情報を持つ `wp-config.php`
- ローカル- ステージ- 本環境
- ローカル- ステージ- 本環境
或いは php にてホストから DB 情報を切り替えるWordPress の場合 wp-config.php は自動生成なので
前者のほうが多い印象キャッシュの設定を wp-config.php に書き出すプラグインもあるので
迷ったらファイルを分けておけば OK
Git 管理のパターン:コア
アップローダのデータ `wp-content/uploads` アップローダのデータ `wp-content/uploads`
• ビットマップデータが殆ど• Git で管理するのは…• .git の肥満化• 運用フェーズではコミットの手間
Git 管理のパターン:コア
Git 管理のパターン:コア
メリット
• コアのバージョンが一致• プラグインが一致• ロールバックが容易• デプロイ時の安心感
デメリット
• 実環境 → 開発環境 が難しい• .gitignore をよく考えないと• 階層がちょっと深い
.vagrant/**/wp-content/local-*.sql
.vagrant/**/wp-content/local-*.sqlコアのパターン +
.gitignore 例
Git 管理のパターン:おまけ
Git 管理のパターン:おまけ
メリット
• Vagrantfile/site.yml• Movefile• ホスト名• 全て一致/設定の手間が減る
デメリット
• 好きな環境を使えない• 深すぎるディレクトリの階層
Git 管理のパターン:おまけ
• チーム全員が Vagrant マシン起こせなくとも• 少数精鋭、皆が同じ Movefile でデプロイ可能• BrowserSync 使うときのIP/ホスト名解決が楽
Git とデプロイ:Git Hooks
因みにサーバの公開ディレクトリで
$ git clone $ git clone
$ git pull $ git pull
して
は手動でもスクリプトでも NG!!
Git とデプロイ:Git Hooks
.git ディレクトリにアクセス可能な状態はソースコードなど見られる危険性
git pull によって発生する merge が意図しない結果を生む可能性も
http://grimoire.ca/git/stop-using-git-pull-to-deploy
Git とデプロイ:Git Hooks
#!/bin/bashunset GIT_INDEX_FILEgit --work-tree=/var/www/html --git-dir=/home/demo/proj/.git checkout -f
#!/bin/bashunset GIT_INDEX_FILEgit --work-tree=/var/www/html --git-dir=/home/demo/proj/.git checkout -f
とかこんな感じで、.git を公開ディレクトリから切り離しmerge の発生しない方法でツリーを展開
Git とデプロイ:WordMove
• WordPress 専用デプロイツール• RubyGems• ローカルとリモートを双方向で同期可能• データベースの同期• データベースバックアップ & ドメイン書き換え
Git とデプロイ:WordMove
• WordPress コア• uploads ディレクトリ• plugins ディレクトリ• themes ディレクトリ• データベース• 上記全て
それぞれリモート → ローカルローカル → リモート
Git とデプロイ:WordMove
$ wordmove help$ wordmove help push$ wordmove help pull
$ wordmove help$ wordmove help push$ wordmove help pull
必要なコマンドとオプションは
で確認
Git とデプロイ:WordMove
設定ファイルは Movefile (YAML)
• インデントが重要 (2スペース)• local の項目は vccw であれば自動設定済み• staging の database と ssh or ftp の項目を入力すれば OK
Git とデプロイ:運用
プラグインやコアを実環境でアップデートした場合
$ wordmove pull -w$ wordmove pull -p$ git commit -m ‘bla bla bal’
$ wordmove pull -w$ wordmove pull -p$ git commit -m ‘bla bla bal’
Git とデプロイ:運用
特定のプラグインのみアップデートを取り消しローカルを残したい時
pull の後
$ git checkout **/plugins/plugin_name$ git commit -m ‘bla bla bla’$ wordmove push -p
$ git checkout **/plugins/plugin_name$ git commit -m ‘bla bla bla’$ wordmove push -p
Git とデプロイ:運用
リモートの uploads をローカルとステージングに
$ wordmove pull -u -e production$ git commit -m ‘bla bla bla’$ wordmove push -u -e staging
$ wordmove pull -u -e production$ git commit -m ‘bla bla bla’$ wordmove push -u -e staging
Git とデプロイ:運用
$ rsync [option] source dest $ rsync [option] source dest
例えば
$ rsync ec2-user@0.0.0.0:/…/wp-content/uploads/ uploads $ rsync ec2-user@0.0.0.0:/…/wp-content/uploads/ uploads
でリモート → ローカルへの同期が可能同じファイル名が存在した場合はリモートが優先される
Git とデプロイ:運用
運用フェーズに入った場合DB は基本的に実環境 → ローカル
ローカル → ステージング
例えば
$ wordmove pull -d -e production$ wordmove push -d -e staging
$ wordmove pull -d -e production$ wordmove push -d -e staging
Git とデプロイ:運用
WordMove の DB 同期がうまくいかない時
WordMove 使えない時は
DB 管理ツール + Search-Replace-DB
https://github.com/welaika/wordmove/issues/78#issuecomment-55882636
Git とデプロイ:運用
リモート ↔ ローカルで普通に便利WordPress に対応していて
wp-confing.php を見つけてくれる
※危険なのでサーバ側はアクセス制限若しくは書き換え後に必ず削除