「外部サービスを使わずにPullRequestベースの開発をするために行ったこと」参加レポート #jtf2015

JTF2015 勉強会 技術

スライド

www.slideshare.net

自己紹介

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の導入

  • サーバーの突然の死
  • マイルストーンの設定などがTracに比べて見づらかった
  • 2013年ごろに盛り上がっていたRedmineã‚„Jenkins同封のALMiniumを導入した

システムの統一

  • wikiとチケットがひとつになった(wikiとticketの横断検索ができるように)
  • リポジトリのグラフ化ができるようになった

残った課題

  • 大量のマージ地獄
  • ビルド職人の属人化（ビルド実行を押すだけなのに、押せるのが自分だけ…）

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

  • 時には共通することも悪いことではない

まとめ

  • 解決したいものを定義した上で挑戦すると失敗しにくい
  • やってみないとわからないことが多いので、まずやってみる
  • 正しいと思う、ワクワクするかどうかも重要

感想

  • 「事前のアンケートでは人気がなかった」と言っていましたが、私は一番聞きたかったセッションでした
  • 聞いた結果も大満足でした
  • 今、自分のところで置かれている状況は似ているので、参考にしたいと思います

JTF2015講演まとめ

nihonbuson.hatenadiary.jp