読者です 読者をやめる 読者になる 読者になる

肉とビールとパンケーキ by @sotarok

少し大人になった「肉とご飯と甘いもの」

PHPカンファレンス2012 で Git と Pull Request をつかったチーム開発の話をしてきました #phpcon2012

PHP

先日 9/15 に行われた PHP カンファレンスで、Git と Pull Request をつかったチーム開発について、発表をしてきました。

資料と補足

まず、発表資料です。

あらためてメインの主張をすると、「Git に移行する」というのは、「svn のコマンドに対応する git のコマンドを覚えること」や、「GitHub Enterprise を導入したら完了」するものではなく、Git を利用した最も効率的な、開発フローや業務フローを考え、チーム開発・運用に適用すること、です。

  • 9/19 時点で、また Speaker Deck の embed が使えなくなっているのでリンクもおいておきます (そのうち対応してくれ、ということで↑は放置)


あと補足っぽいものを

  • gitflow のブランチ戦略について説明しましたが、ちょっと複雑だなーと思う方には、GitHub Flow も人気のようです
    • https://gist.github.com/3705015
    • ブランチ運用自体はシンプルで良いなーと思うのですが、いろいろ懸念点もあるので、両方の良いところを取り入れつつ今後もいろいろ改良を続けたいです!
    • GitHub Flow で運用している人にはちょっと聞いてみたいこともあります。どこかでよろしくお願いします。
  • 2つ前にあった、@halt さんによる、「最先端Web開発」の発表ですが、開発フローややり方は違うのに、同じ結論にたどり着いているのが面白いなーと思いました。Git / Pull Request (あるいは、ペアプロ・グループプログラミング) によるメリットは、やはり、チーム全体としてのコードの品質を高めていくことができるようになる、ということなんですよね。
  • Twitter などでのフィードバックも見させていただいております。結構良い反応をいただけてうれしいです。

Ustream の録画

Ustream 配信も行われていて、録画は以下でみることができます。

Git ツール選択チャートつくりました

GitHub有料版のほうがいいよねとか、GitLabっていのかしらとか、いやいやGitHub Enterpriseのほうが、いろいろ迷うと思いますが、よくある Y/N のチャートを作りました。(雑)
僕なりの視点ですが、何かの参考にしてください!緑がYes、赤がNoです。


一応解説すると、

  • お金がたくさんあるなら、GHE使うのが一番よいです
  • Git サーバのメンテナンスがしたくないなら、何人メンテナがいても GitHub の Private はprivate repository 10個で $25/月、20個で $50/月 ですし、年間でも5万くらいなので、よいです。
    • 一応、リスクとして考えなければいけないのは以下のあたりです:
      • 3ヶ月に1度くらい落ちたり、メンテナンスされたりします。その間 push できないとか、リリースできないとかは、我慢したとしても、自前でサーバをメンテナンスするよりはペイする、という判断もあると思います。
      • push を我慢するとしてもデプロイが GitHub に依存するのは嫌だなーというのが僕の意見です。ただ、繰り返しになりますが、それも、たまになので、日々メンテすることのコストと比較してもペイするでしょ、という考え方も、あります。
      • ソースコードは GitHub に預けることになります。
  • GitLab のインストール時点ですんなりできなかった場合、今後の困難が予想されるので、やめた方が良いかもしれません
    • GitLab にすることのデメリットは:
      • GitHub と比較して機能的に劣る
      • メンテナンスコストがかる (金銭的・時間的デメリット)
    • 事例からいって、メンテコストとは、以下のものです
      • Gitサーバを動かすサーバを借りる金銭的コスト (VPSなど)
      • バックアップ処理が必要 (まぁ、一度つくれば、cron とかで回せば良い。うちは S3 にアップロードしています)
      • 月に1回、バージョンのアップグレード作業をする (1時間程度)
      • 動かしているGitサーバが壊れたりしたら、GitHubが落ちた時以上に面倒 (新規サーバ作成、バックアップから再構築)

といったところです。

それから、発表資料にもありますが、「多少バグっても許される程度の小規模なチーム」でおすすめでしています。たとえば、大きな会社になると、多少バグっただけでも、ヤンヤヤンヤと社シスへほかの開発者からクレームが来ます。そういう状況はつらいのでGitHub使った方が良いでしょう。

発表中、GHE or GitLab でしょ、といったのはまさにそこで、社シスへクレームが飛ぶような大きな会社なら、お金払って GHE 使った方が総合的に享受できる利点が大きいのではないでしょうか。

スポンサーもしていました

クロコス (Crocos, Inc) では、PHPカンファレンスのスポンサーもしていました。

で、クロコスはめちゃくちゃおもしろいので、エンジニア大募集してますし、声かけてください!

ちなみにこの場を借りて宣伝しておくと、

  • PHP/JS を書いていただくことになります
    • 技術的経験からいうと、PHP以外の言語に精通した人でも採用条件としては、かまわないと思っています。が、実務は PHP ですので、PHP は絶対に書きたくない、という人以外にオススメです
  • Git 使います
  • 別にそれがすべてではないですが、お声がけいただく際には GitHub のアカウントも教えていただきたいです
    • コードを見るのが一番話が早いです

よろしくお願いします!

スタッフもしていました

今年はなにかとバタバタしていてほとんどお手伝いできなかったのですが、一応スタッフとしてもお手伝いしていました。
たくさんの仕事をかかえこみながら運営してくれた安藤さんをはじめ、スタッフの皆様、お疲れ様でした。

PHP カンファレンスは、毎年、本当に、ゆるゆるとですが、ちゃんと有志ががんばって開催しています。今回、参加してよかった、来年もやってほしい、自分も手伝いたい、などという方は、是非来年実行委員に入ってください!

というわけで

今年も盛大に閉幕したPHPカンファレンスですが、スポンサーの皆様、参加された皆様、Ust参加の皆様、僕の発表を聞いてくれた皆様、ありがとうございました。
そして、WordCamp のスタッフと、PHPカンファレンスのスタッフの皆様、お疲れ様でした!

参加者アンケートあります:

PHPカンファレンスFacebookページもあるのでいいね!してね!: