pull request based development
TRANSCRIPT
Agenda
• Problems in 2010
• Why Modern?
• Pull Request and ChatOps
• TIMTOWTDI and BSCINABTE
• Conclusions
Start from here
• Trac and hiki and Subversion
• Ruby 1.8.7
• Gitが浸透していく時期だった
• 制約上プログラムを外にださない
• 外部のChatの使用は禁止
HikiTrac
Subversion
Staging
Programmer
Infra or PM
Build Staging Deployしまーす
Deploy お願いしまーす
cap deploy
HikiTrac
Subversion
Programmer
Infra or PM
こ、、、これは
Merge お願いしまーす
TOPIC-XXX
TOPIC-XXX
TICKET-DDD
TICKET-DDD
FEATURE-XXX
svn checkout
branch説明
ticket記入
What is Problems?
• タスクとソースで2つのツールを行ったり来たり
• マスターの中央管理のためコミットにrefsを付けないと個人のコミットがほぼ状況が負えない。(グラフ表示がない)
• リポジトリのmaster用とdevelop用で取りまとめがProgrammerとInfraで別れていたため全く知らないInfra or PMがたまにmerge地獄に会う
• プロジェクト・機能・チケット毎にブランチを切っていたら100以上のブランチ
• デプロイ出来る人が限られてる
My team is slow…!?
• Speeeed?
• Mergeにすごく時間がかかり、どんどん差分が開く
• deployやサーバーの運用をいちいち依頼するのが手間
• commitミスすると、みんなに連絡して~revertして~のコスト
• Traditional?
• GitHubより流れがGitになっていた
install Gitlab
• 各々GitHubのアカウント作成し、プライベートでgitを始める
• 無料でサクッと試すためにまずはGitlabを入れた
• 突然の英語環境に困惑するもgitになれるため何度もペアオペ
• 当時Pull Requestの良さ知らず、今までのやり方をそのまま
リモートリポジトリの安定
• 個人でcommitを重ねて行えるようになった
• リモートリポジトリを壊す心配が減った
• 挑戦して満たされるエンジニア心
• しかし、運用がそのままなので、gitに詳しくなっただけだった
install ALMinium
• 当時Gitlabのissueだとtracに比べ、見難い
• サーバーの突然の死もあったことで、改めてRedmineとJenkins同封のALMiniumをGitリポジトリで利用することにした
システムの統一
• wikiとticketとソースがひとつになった(wikiとticketの横断検索は便利)
• お手製のビルドサーバーからJenkins導入(しかし使う人は同じ)
• Redmineもtracと同じ運用可能(ticket一覧画面で自身専用にカスタマイズできるのが良かった)
• リポジトリのグラフ化で視覚的にわかりやすくなった
githubkaigi.org
• Pull Requestの凄さを知る
• hubot によるChatOpsを知る
• 同じように課題持っていることを知る
Pull Request
※1 rebaseすることで、Pull Requestの際に自身のcommitのみだけ表示される
local remote master
remote fork
remote master
upstream
merge
git pushorigin
pull request
git rebase※1
Pull Requestのお作法
• WIP(Work in Progress)
• マージ出来る状態でPull Requestを送る
• マージ前にコードレビュー
• masterはいつでもデプロイ可能
• 自分の作業コミットだけする(rebaseする)
• 終わったブランチはdeleteする
ChatOps
• Chat機能を持つコミュニケーションツールとHubotを利用して運用に関わる様々なタスクを自動化
• 何が起こっているのか、関係者全員が把握しやすい
• 複雑な構成のシステムや開発構成でも情報、操作を一箇所に集約できる
• ビルド通知をChat上にする
• ビルド指示をhubotに指示
• hubotの投稿をデスクトップ通知にして把握
private?
• GitBucket
• ver3.1 Jenkins pull-request builder可能
• kandan(~2015/06)
• lets-chat(2015/07~)
Hiki Trac
Subversion
Staging
Programmer
Infra or PM
Chatcap deploy
ALMinum
@hubot jenkins build app
2015/07~入替
2014~
プロジェクトを超えたビルドの確認
※ kandanから切り替えた理由は、アプリが軽い、最近作られたためメンテが早い、独自のemojiが使える、デスクトップ通知がある、一画面の情報量が多い、Heroku buttonで試しやすいetc…
通知をマークで表すとわかりやすい
青色マークでわかりやすいビルド青色マークでわかりやすいビルド@hubotからビルドを指示
プロジェクトを超えたビルドの確認
TIMTOWTDI
• “There Is More Than One Way To Do It" Tim Toady
• いろんなやり方があってもいい
• Repository is Subversion? Git?
• development tool is Redmine?Gitbucket?Trac? Hiki?
• Jenkins auto workflow?cap手動?
BSCINABTE
• “But Sometimes Consistency Is Not A Bad Thing Either” Bicarbonate
• 時には共通のやり方があってもそれは悪いことではない
• 共通のやり方=ChatOps
• 複数の環境に対して通知とビルドを共通のやり方
Conclusions
• 解決したいものを定義した上で挑戦すると失敗しにくい(初回のGitlabの運用失敗経験が良かった)
• やってみないとわからないことが多いので、まずやってみる
• 正しいと思う/ワクワクするかどうかも重要
• TIMTOWTDI and BSCINABTEの考え方で作るとチームにそこまで混乱は起きなかった
• "Better late than never "- 「遅く来てもやらないよりまし」
Show Note
• trac http://trac.edgewall.org/
• subversion https://subversion.apache.org/
• hiki http://hikiwiki.org/ja/
• redmine http://redmine.jp/
• ALMinium https://github.com/alminium/alminium
• GitBucket https://takezoe.github.io/gitbucket/
• kandan https://github.com/kandanapp/kandan
• lets-chat https://github.com/sdelements/lets-chat
• Githubkaigi http://githubkaigi.org/
• 伊藤直也が語る「仕事の流儀」 https://codeiq.jp/magazine/2014/07/12464/
• システム開発・運用の「自動化・効率化・可視化」に無限の可能性を!チャットルームにHubotさんを招聘してChatOpsを始めよう #hubot #chatops https://codeiq.jp/magazine/2014/11/17130/