Shirohanada開発体制

Shirohanadaの開発環境

今回Autumnskyのテーマは3代目。8年目にして3代目というローペース更新。
「ここは本式に最先端ツールでやってやろう！」と色々と最先端を導入（Vimを除く）

OS: Windows10
エディタ: Gvim香り屋版
ローカルWordPress実行環境: Wocker
CSSプリプロセッサ: Stylus
タスクランナー: Gulp (過去形)
バージョン管理: git
進捗管理: Redmine
コードホスティング: GitHub
CI: TravisCI

ツールとかサービスの連携図 CentOSは自宅サーバです。

ローカル実行環境 Wocker

最初はVCCWを使っていたのだが、結構重い。
2016年1月にWocker Ver1.0がリリースされて、Windowsで試したところあっさり走った。
(Ver0.8で導入してみたが、どうしてもWordPress本体が表示できなかったので諦めていた）
Twitterで動作報告をしたところ、ちょうどWindowsでの動作確認が欲しかったらしく、ジャストタイミングでの動作報告だったようだ。
私もWordPress周りに貢献できたので嬉しい。
Wockerの使い方は下記、2記事を参照して下さい。

軽くて楽です。
思い立ったら1分でWordPressが立ち上がります。
なので気軽にスタイルを直したりできます。
WP-CLIも使えます。
テストデータのインポートを試しましたが、私の環境ではダメでした。コマンド自体は走っていますが、何かしらファイル読込でエラーが出ているようです。
結局ダッシュボードからインポートして使ってます。

ブランチモデル

master-release構成としています。
GitHubFlowなどを眺めていて、「一人でやるには複雑すぎる」と感じていたし、実際に試そうとして収拾がつかなくなった。gitを使ったフローについてはSourceTree開発元のAttrasian社による解説ページが参考になった。調べるうちに、POSTDのこの記事で紹介されたGitLabフローがよさそうだった。

GitLab flowから学ぶワークフローの実践

またWordPressのテーマ作成では、StylusのCSSメタ言語ファイルやNode.jsモジュールなど、開発には必要だがテーマとしては不要なファイルが多く含まれる。
なので、やはりテーマもビルドした方がよさそうである。

最近のWordPressのテーマ開発はgulpとかを使ったりするので、それを公式ディレクトリに登録する時とか本番環境で使う時には、厳密には不必要なファイルが大量に生成されたりします。
あと、npm installとかでよそから持ってきたファイルも、できればGitには登録しないほうがいいです。
そんなわけで、最近のWordPressのテーマ開発では、不要なファイルの削除とか外から持ってきたファイルを同梱するとか、そういうビルド作業が不可欠になってきました。
WordPressのテーマをTravis CIでビルドする。 @miya0001

そこで、当方もテーマに必要なPHPとCSSのみのファイル構成にしたreleaseブランチを作ることにした。
機能追加・バグ修正はフィーチャーブランチを作成して作業するつもりだったが、一人なのでいきなりmasterへコミットしている。
たまにフィーチャーブランチは切ります。

TravisCIによる自動ビルド・テストと自動デプロイ

GitHubのmasterへプッシュすると、ビルド-テスト-デプロイが自動で走ります。
特にビルドは手作業で毎回やるのが煩わしく、間違えて必要ファイルを消してしまうとデプロイ後に面倒が起きかねない。
テストは方法が分からなかったので、大したことはできておらずPHPの文法チェック程度。
WordCamp関西2016でWordPressテーマの継続的インテグレーションというセッションがありまして、
こんな方法があるよというのを知ったので、このテーマでも近々自動テストを組み込む予定ではありますが。
先のWordPressのテーマをTravis CIでビルドする。記事と合わせてGithub から WordPress のテーマを自動更新するとめちゃくちゃ快適だった。を参考に、自動ビルド-テスト-デプロイの仕組みを整えてます。
masterへマージしGitHubへプッシュすると、それをトリガーとしてTravisCIが「発火」し、テスト・ビルド後にreleaseブランチへ自動マージされる。

GitHub masterブランチへプッシュ
プッシュされたmasterからTravisCIがpre-release ブランチを切る
不要ファイルの削除と、PHPの文法チェック
TravisCIのpre-releaseをGitHubのreleaseへマージ

これで、配布可能な形のテーマができあがります。
releaseへコミットされたタイミングで、自動デプロイが走ります。

releaseブランチがコミットされる
GitHubにより、更新内容が指定URI=レンタルサーバへポストされる
レンタルサーバのWordPressプラグインWP-Pusherが受け取る
本番用テーマが更新される

この5～8の手順はこのブログでも書きました。
WordPressのテーマを自動デプロイする
masterへプッシュするだけでここまで走ります。
本番テーマアップデートまで最短3分。

Redmineとgitリポジトリを連携させる

進捗管理はGitHubでやろうかとIssueを切ってみていたのですが、粒度が大きいというか、あまり上手く進捗と今後の見通しが把握できなかった。
そこで自宅のファイル置き場兼録画サーバー=CentOSに数年前にインストールして放置されていたRedmineを本格的に使ってみることに。
テーマは以前から気になっていたminimalflat2を入れるべくRedmineのバージョンアップから。
これが結構、難航しましたが（RailsのアップデートとC++コンパイラを自前ビルド）使いたいツールから入るのもありだなと思いました。
さらにサーバーにgitを入れておく。gitは分散型なので「同じコード」を2カ所に置いておくのも訳はない。
Wocker内にある開発用のgitリポジトリのリモートを、自宅のCentOSとGitHub二つにします。
これで、RedmineとGitHub双方に手元の開発中コードをプッシュすることができます。
そしてRedmineにリポジトリを登録します。
チケットを切る、コードを修正する、コミットする。Redmine管理リポジトリへは適宜プッシュ。
コミットメッセージにチケット番号を書いておくと、チケットに自動で反映される。
下の「関係しているリビジョン」として表示されます。

デプロイできる所まできたら、GitHubへPush。
それだけで、自動でデプロイまでやってくれます。
リリース版はTravis CIで作成されてGiHubへ反映されるので、PCへ一回PullしてからRedmine管理下のリポジトリへPushします。
バックアップにもなっていいのかなあと思います。

まとめ

再び図。
ローカルの開発用PC（Windows10)を中心にgitを使っていくつかのツール・サービスを連携させている。
特にGitHubを利用した自動ビルド-デプロイは本当に楽になります。

使いやすく快適な開発環境は、モチベーションが上がります。
そして、コードを書くことに集中できます。