僕たちの行っている小規模WordPressウェブサイト開発のワークフロー@2016年

はじめに

小規模〜中規模のウェブサイト開発を行っています。
自分たちのワークフローの紹介と言いますか、いくつか気をつけていることなどについて纏めます。

開発フレームワーク

現在の所ほぼWordPressで開発しています。
WordPressがフレームワークか、という議論もありますが、以前にPHPカンファレンスでラスマスさんだったかな、の言っていた「WordPressはフレームワークだ」を聞いて以来そう考えています。

役割と人員、チーム

必要となる役割はだいたい以下の通りです。

• マネージャ、ディレクター
• コーダー
• デザイナー
• プログラマー

これらの役割をこなせる人が、2人〜3人ほど割り当てられます。
役割に対して人員が少ないことがほとんどなので、兼任することが前提です。

タスク管理

修正依頼などをチームで共有する場合、Redmineを利用しています。
小規模サイトでは特に重要だと思っていますが、Redmineで気をつけていることは

• タスクの作成に時間を掛けない
• スクリーンショットを多めに付ける
• URLをつける

ことです。
「小規模サイト＝予算が少ない」ということですので、一つのタスク作成に時間を書けているとコストがかさみます。また小規模サイトの場合には仕様変更に素早く対応することも重要になりますので、堅めの仕様より柔軟な対応を重視したほうが良いです。

スクリーンショット、URLについては問題の確認や再現のために重要です。
エラーメッセージのテキストデータを記載することも良いですが、スクリーンショットの方が分かりやすかったりもします。

チケットを作るのは一分以内を目標としています。

Redmineのプロジェクト名

下の方にも書いてありますが、プロジェクト識別子には日付を付けるようにしています。
平行している案件が多い場合、プロジェクト識別子でソート順がかかるからです。

現在僕の参加しているプロジェクトが20件ほどあり、プルダウンからの選択が結構ストレスです。
ブックマークなども併用していますが、並び順は重要かなと思います。

バージョン管理とファイル管理

バージョン管理

バージョン管理にはGitを使っています。
ブランチやプルリクエストは使わず、チームメンバーがmasterに直にコミットしてもらっています。

SourceTree

GitのGUIクライアント、SourceTreeを使っています。
https://www.sourcetreeapp.com

エンジニアの自分も、非エンジニアの他のメンバーにとってもGUIというのはありがたいです。

以前にGitHubから同名のGUIアプリが出たときに「これでチームにGitを使ってもらえる！」と胸を躍らせた覚えがありますが、いろいろとあって残念ながら導入障壁は高かったです。

SourceTreeすごく良いです。

案件のスラッグとリポジトリ名

案件ごとに一意な（ユニークな)呼び名、スラッグを付けるようにしています。
例えば「株式会社 ホゲデザイン」さんのリニューアル案件であれば、hogedesignというスラッグを付けています。
このスラッグはリポジトリ名、Redmineのプロジェクト名、WordPressのテーマ名などに採用しています。

リポジトリ名にはリポジトリを作成した日付 + スラッグを付けるようにしています。
小規模な案件が平行して進んだ場合、ディレクトリを探すのがなんだかんだで大変になります。
日付を付けておくとFinderでリポジトリを探す際にフォルダ名でソートすれば、新しいものが見つけやすくなります。

日付の付与とターミナル操作

日付を先頭に付けるというのにはデメリットもあります。
ターミナルから操作する場合に日付が先頭にあると入力が面倒になります。

これについてはzsh + oh-my-zshを使うことでうまく補完できるようになります。
zsh+oh-my-zsh (もしかしたらプラグインかも？) ではディレクトリやファイル名の一部で補完することができるようになります。

例えば先ほどの20160718hogedesignというディレクトリを指定する場合には、

$ cd ~/git/hoge <TAB>

とすれば 20160718hogedesign が補完されるので日付を入れる必要がないので楽に補完することができます。

Bitbucket

GitサービスはBitbucketを利用しています。案件で一つのリポジトリを作ると数が増えるのでGithubよりBitbucketを使っています。
https://bitbucket.org
インタフェースも軽快でわかりやすいですし、非常に助かっています。

と思ったのですが現在は

個人利用の場合、月額7ドルでプライベートリポジトリが無制限に作成可能になった
https://codezine.jp/article/detail/9434
とのことです。

リポジトリの展開場所

個人の好みがありますがホームディレクトリにgitというディレクトリを作り、そこにリポジトリを並べています。
例えば Mac OS Xであれば

/Users/yousan/git + /20160718hogedesign
                  |-/20160718fugaworks
                  |-/20160718piyomaterial
                  |-/20160718doremifood

という感じにディレクトリを作っています。
ローカル開発環境のpublic_htmlの中に置いたりしたこともありますが、場所が分からなくなったりするので~/gitに作るということで統一しました。

リポジトリ内のディレクトリ構造

• お客さんとやりとりしているファイル
• 作成するWordPressのテーマ
• 作成するプラグイン
• その他SQLファイルなど

に分類しています。

具体的には

• attachments/
• themes/
• plugins/
• etc/ や sql/

としています。

添付ファイルは階層構造とならずに増えて行く場合が多いので、ファイル名の先頭に日付を付けるようにしています。
まとまった添付ファイル群はディレクトリを作成しています。

デザインデータ

デザイン系のaiファイルなどもリポジトリに入れるようにしています。
規模が少し大きくなるとあふれかえることがあるので、その場合にはデザイン系のリポジトリとコード系のリポジトリを分けると良さそうです。

デザインデータがあって数GBとかになるとcloneが大変になります。

開発用ドメイン

ローカルの環境では

スラッグ + .dev

というルールにしています。
例えば本サイトが「example.com」の場合には「example.dev」をローカルの開発用ドメインとします。

色々と試しましたがここに落ち着きました。

過去には

• 案件のスラッグ+ホスト名
• 案件のスラッグ+.local

を試しましたがここに落ち着きました。
「.local」はMacOSとの相性が悪く、DNSの解決ができなくなったりしました。
下記のBonjourが原因かなと思っています。

https://support.apple.com/ja-jp/HT203136

初めはHostsファイルの書き換えをしていましたが、resolver + dnsmasqを設定してしまえば.devの全てがローカルになるので便利です。

また.devで統一しておくと、開発者間でのWordPressのDBデータのやりとりをするさいにsiteurlなどを書き換える必要がないのでスムーズです。

連絡ツール

特に取り決めをせずにチームで使いやすいものを使っています。

音声通話

• Skype
• TeamSpeak
• FaceTime

チャット

• Slack
• FaceBookメッセージ
• LINE
• Chatwork

メジャーどころは紹介するまでもありませんが、あまり使われて居なさそうなTeamSpeakについて紹介します。
サーバクライアント型の音声チャットツールで、利用にはクライアントソフトの他にサーバが必要です。
Teamと名前が付いているとおり、1対1より多人数での音声通話に向いています。
通話品質を下げることができ、CPU負荷や回線負荷をコントロールすることができます。
スピーカー通話時のエコーキャンセルなどもマニュアルで選ぶことができます。
発話中かどうかの判断や、自分からみたメンバーごとの音量調整が可能です。
Skypeはその辺りを自動でやってくれますが、手動でやりたい場合には便利です。

データベース

WordPressを使っているとデータベースの同期をする必要があります。
これについては今のところ解決策がなく、手動でダンプしてインポートしています。

まとめとかその他

エンジニアのリードとメンバーの尊重

僕が案件に入る際にはエンジニアとして入ります。他のメンバーは非エンジニアの方なので、GitやRedmineなどのツールに慣れているとは言いがたいです。
そういった新しいツールの導入については他のメンバーの負担にならない範囲で導入の支援を進めていく必要があります。
エンジニアが便利だと思っても立場によってはそれほど便利と思ってもらえないこともあります。その際に他のメンバーの意見や気持ちを尊重することが重要だと思っています。

将来的な変更

開発時のとりきめについて変更をしすぎると慣れることに時間を取られてしまいます。
案件が切り替わる際に少しずつ変更していっています。
WordPressはcomposerでの管理が盛んになってきていますので、近いうちにcomposer+.gitignoreでの管理を考えています。

データベースの同期とWordMove

データベースの同期は手動で行っています。WordMoveという非常に便利なツールがあるのですが、残念ながらバグがちで動かないことがおおいです。

メンバーによっては環境にRubyが入っていないことも多いですし、ターミナル操作というのも敷居が高いです。
wp-cliに取り込まれたらバグがなくなるのではないか、と密かに期待しています。

仮想化環境

VCCWやDocker、Scotchなどについては全体では導入していません。今後の検討です。