Pull Request でMTMLのレビュー？

MTMLのバージョン管理
http://mersy.github.io/mtmlVersionControl.html

この話に通じるところがあるのかもしれないけれども、Pull Request ベースの開発とかのスライドを見ながら。

「GitHubでつくる、たのしい開発現場」YAPC:ASIA Tokyo2013 | Act as Professional - hiroki.jp
http://hiroki.jp/yapcasia-2013-github

プロジェクトに使うMTMLをGithubとかで管理はしてて、それのレビューとかをpull requestすることはできそうなきがする。

できそうなきはするんだけど、一度MTに入れて動くかどうかを試さないといけないというのが難しいところなきもする。

プログラム書かれてる方々はテストとかそういうのをまわしてるんだろうけど、MTMLを書くことをコードを書く、というのと大体同義に扱うと、テストと同じあたりの位置づけになるんだろうなぁ。
MTの環境がサーバーに1つしかないとかなると当ててテストなんて出来ないし。
んじゃ案件ごとにローカルに環境をおければいいんだろうか。。それが現実的なのかなぁ、、、、

プログラムを書くか、テンプレートを書くかということで根本的に違う話で、そのまま当てはめることが出来ない、ってのもあるんだろうな。

非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
http://blog.madoro.org/mn/93

具体的には、N個(N=アクティブな開発者の数くらいが良さそう)のfeature branchのテスト用のHeroku appを予め作っておいて、feature branchにpushされるたびに、Jenkinsからその中の一つへデプロイされる感じにした。

こういう環境が用意できれば、branch on MT 的なイメージはだいぶ進められるんじゃないかなぁ。1つの検証環境に紐尽く複数の開発環境。開発環境でOKの物がどんどん検証環境にpushされていくイメージ。
開発も確認もダイナミックに進められれば問題はなさそう。

また、開発者も、それまでは、merge後、非開発者に指摘されると「めんどくせーなー」という意識が生まれがちで、かつ、その場合mergeから時間が経っていることも多く、その変更に対するフレッシュさが減り、再度作業を始めるまでの心理的な負担(実際、実装を思い出すための脳のコストも高そう)も高かった。それが、pull-request中に非開発者からフィードバックが貰えることで、そのpull-requestにcommitを追加することだけでさくっと修正できて、全体のスピード感がとてもあがったし、開発者の負担も減った。

2つも3つも進んだと思ったら、またスタートへ戻るというのはやっぱり負担が大きいよな。。。