夏サミ感想(グリーを支えるソーシャルコーディングのすべてについて)

by @dekokun on 2012/07/29

Tagged as: 勉強会.

「ブログ環境が構築できてないから旧ブログで書こう」というのを繰り返していると新ブログ環境を構築していく気概が失われるのでこちらで書きましょう

夏サミとは

「グリーを支えるソーシャルコーディングのすべて」のまとめなど

  • このセッションだけ参加しました
  • togetterまとめはこちら http://togetter.com/li/345680
  • 講演してくださったのはグリー株式会社開発本部 CTO室 エンジニアの大場光一郎さん(@koichiroo)
  • 大場さんは開発環境全般の改善などを行なっていらっしゃるそう
  • グリーがGitHubを導入していたのは一時期話題になっていたので知っており、GitHubを使用してpull requestのワークフローを行なっていることも小耳にはさんでいたため実際にどのようなワークフローを行なっているかを知りたくて参加した

内容まとめ

グリーの課題

  • 急激な増員 現在、月に50人ほどずつ増加中

  • 業種の増加 1口にエンジニアと言っても、細分化され(Web、ネイティブアプリ、ネットワークなど)業種が増えてきている

  • 国際化 日本にも英語ネイティブが増えており、また、グリーは世界各国に計9拠点あり現地のエンジニアも増えてきている

周辺の動向

  • SVNからGitへの移行真っ盛り Gitを更に便利にするため、GitHubが出てきている

GitHubの利点(便利な点)

  • Forkができる
  • pull requestができる(自分でバグを直せば開発元に変更を教えて上げることができる！)
  • Githubはソーシャルグラフを持っている(PJ中心ではなく人間が中心になった)
  • Git導入により分散repoによって複数人でのシステム開発がやりやすくなったが、GitだけではPJを越えて開発するための機能が足りない

グリーのバージョン管理の歴史

  • 2004~ SVN
  • 2010~ Git
  • 2012~ GitHub導入

GitHub導入の目的

  • OSS開発でよいとされている手法を導入
  • PJ間のコラボレーション機能
  • 埋もれているプログラムの発掘
  • 国際化対応(どの国のエンジニアもGitHubは使用しているためアカウント情報だけ教えれば使ってくれる)

実際の効果

  • 以前はgitsisを使用していたのだが、gitsis時代はリポジトリメンテナみたいな人がいて、申請が必要だったした。するとソースコード公開が面倒なので行わなくなる
  • GitHub導入によって、リポジトリはひとりいくつでも手軽に作成可能に
  • ログイン方法さえ教えておけば、外国の人もすぐ使える！！
  • 誰が何を開発しているか可視化(あのPJの担当者は誰かとか)
  • 手元で書き捨てるようなコードも共有可能に
  • 作った人でなくても修正して使い続けられる
  • プログラム作成者が退職したりPJに興味がなくなりメンテされなくなっても、別の人によってメンテされる！！(更新されないプログラムは死ぬが、GitHubはソフトウェアの寿命を伸ばしてくれる)

ガイドライン

  • Githubを使用したワークフローとガイドラインをしっかり作るのが課題。現在整備中
  • GitHubを企画、デザイナーにどう使っていってもらうか(PJ全体に使ってもらう方法)を模索している

GitHubエンタープライズについて

  • ソースコードを社外に置くのは難しいという会社のためGitHubエンタープライズがある(社内にGitHubサーバを建てられる)
  • グリーでは、GitHubエンタープライズを使用(Social or security)(人数が増えれば、エンタープライズでもソーシャル性がある)
  • GitHubエンタープライズを使用する場合、使用ユーザが少ないとせっかくのGitHubのソーシャル性が犠牲になる
  • 実感として、使っているユーザが100人くらいだとGitHubのもつソーシャル機能を活かすのは難しい(現在のグリーの人数ならば大丈夫)
  • サーバを自分たちで運用をする必要がある(そんなに手はかからないが、何度かダウンはしている)
  • 動作が重くなる場合も(リポジトリ数が1000、ユーザ数が500くらいで仮想サーバを増強した)
  • GitHubのアップデートに追従するためのアップグレード機能がある
  • 管理コンソール(SSHでメンテナンスできるような裏コマンドもある)
  • LDAP認証可能

質問など

私の欲していた、GitHubを使用したワークフローに関して質問してみました

  • Q. pull requestのワークフローを導入しているという話を聞いたが、実際どうか
  • A.チームによる。本流への反映をpull requestのみで行なっているチームもあり、バグ発生が目に見えて下がった
  • Q. pull requestのワークフローなど導入する場合、プロジェクトのメンテナがいて、メンテナがpull requestを反映するような形で行なっているのか
  • A. メンテナがいるわけではなく、チーム全員でレビューをし、その後pull requestをマージする。ブランチ作成などのワークフローについてはは自社で作成したgit dailyというツールを使って行なっている

その他、他の方の質問など

  • Q. デザイナやディレクタにGitを使用してもらうためにどのようなことを行なっているか
  • A. デザイナなどでアンテナの高い人を探し新GitHub派を作りその人達に教え、他のデザイナには新GitHub派の人から良さや使用法を伝えてもらう

他にもいくつか質問はありましたがメモしていない…

以上です。

感想

pull requestのワークフローなどについて、簡単にでも伺えたのでよかったです。また、運用についてなど、実際に導入してしかわからないことが聞けたのもよかったです。

pull requestのワークフローは自分で少し行なった限りでは非常に使えるものだと思っているので(GitHubのpull requestのUIはコミットとコメントが時系列順に並び、コードレビュー的な観点から非常に強力。「ここ直せ」「直してpushしました」「ナイス!」みたいなやり取りがしやすい)、私のほうでももう少し使って利点を発信していきたいです。

グリーのGitHubを使用したワークフローについてのブログ記事なども今後出てきて欲しいなど思いました。

誰が何を行なっているかの可視化もできるというのはある程度大規模な会社では有用だと思った

その他夏サミに関係ない話

  • このブログ、スタイルシートなどほとんど使用しておらず、真っ白なブログですね。ヘッダフッタナビゲーションもないし。
  • Initializr使おうかな
  • このブログはHakyllを使用しており、HakyllはMarkdownをHTMLに変換するのにpandocを使用しているのだが、pandocの変換エンジンはネストしたリストを取り扱えないようだ。
comments powered by Disqus