スライド
www.slideshare.net
自己紹介
- 坂部広大
- ツイッターアカウントは@koudaiii
- 2010年入社
2010年の社内環境
- Trac and hiki and subversion
- Ruby 1.8.7
- Gitが浸透していく時期だった
- 制約上、プログラムを外に出さない
- 外部のChat使用は禁止
- Tracでチケットを見ながら、Subversionに上げていく
- 内部に入れるのは正社員のインフラのみ
- アプリケーションエンジニア「Deployお願いします！」
- インフラエンジニア「今からDeployします！」
- アプリケーションエンジニア「Mergeお願いします！」
- インフラエンジニアもしくはPM「Mergeが大変…」
問題点
- タスクとソースで2つのツールを行ったり来たり
- SubVerisonなので中央管理なので、コミットにrefsをつけないと個人のコミットが状況が追えない
- グラフ表示がない
- ログを追うしか無い
- インフラもしくはPMがMerge地獄にあう
- プロジェクト毎にブランチを切っていたら100位上のブランチ数に…
- Deployする人が限られている
- スピードが遅い
- Mergeに時間が掛かる
- Deployを依頼するのが面倒
- Commitをミスすると、みんなに連絡してrevertしてのコストがかかる
選択する上で大事にしたこと
- イラッとする部分を解決したい
- ワクワクする
- 世の中を見てお作法的になっていることは取り入れたい
- プロダクト毎に最新を提供
GitLab導入
- 無料でサクッと試す
- Gitに慣れるためにペアオペ
- 当時、Pull Requestの良さを知らず、使い方はSubversionと変わらず
リモートリポジトリの安定
- 個人でcommitを重ねて行えるように
- 壊す心配が減った
- ただし運用がそのままなので、gitに詳しくなっただけだった
ALMiniumの導入
システムの統一
残った課題
- 大量のマージ地獄
- ビルド職人の属人化（ビルド実行を押すだけなのに、押せるのが自分だけ…）
Githubkaigi.orgに参加
- プルリクエストの凄さを知る
- hubotによるChatOpsを知る
Pull Requestのお作法
- 空コミットしてWork in Progress
- マージできる状態でぷる陸を送る
- マージ前にコードレビュー
- マージしたらそのブランチを消す
ChatOps
- コミュニケーションツールにHubotを利用する
Privateにするために
- GitBucketの導入
- kandan(-2015/06)
- lets-chat(2015/07-)
現在
- サーバーは多くなった
- ただ、チャットを通して誰でもDeployできるようになった
TIMTOWTDI
- There Is More Than One Way To Do It
- どんなツールがあっても良い
BSCINABTE
- 時には共通することも悪いことではない
まとめ
- 解決したいものを定義した上で挑戦すると失敗しにくい
- やってみないとわからないことが多いので、まずやってみる
- 正しいと思う、ワクワクするかどうかも重要
感想
- 「事前のアンケートでは人気がなかった」と言っていましたが、私は一番聞きたかったセッションでした
- 聞いた結果も大満足でした
- 今、自分のところで置かれている状況は似ているので、参考にしたいと思います
