Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Pull request based development

9,010 views

Published on

July Tech Fest 2015
2015/07/26

Private空間で開発環境をモダンにしていく話をしました。

Published in: Technology

Pull request based development

  1. 1. Pull Request based development @koudaiii
  2. 2. Profile • id: ‘koudaiii’ • fullname: ‘Kodai Sakabe’
  3. 3. Agenda • Problems in 2010 • Why Modern? • Pull Request and ChatOps • TIMTOWTDI and BSCINABTE • Conclusions
  4. 4. Problems in 2010
  5. 5. Start from here • Trac and hiki and Subversion • Ruby 1.8.7 • Gitが浸透していく時期だった • 制約上プログラムを外にださない • 外部のChatの使用は禁止
  6. 6. HikiTrac Subversion Staging Programmer Infra or PM Build 2010~ cap deploy
  7. 7. HikiTrac Subversion Staging Programmer Infra or PM Build Staging Deployしまーす Deploy お願いしまーす cap deploy
  8. 8. HikiTrac Subversion Programmer Infra or PM こ、、、これは Merge お願いしまーす TOPIC-XXX TOPIC-XXX TICKET-DDD TICKET-DDD FEATURE-XXX svn checkout branch説明 ticket記入
  9. 9. What is Problems? • タスクとソースで2つのツールを行ったり来たり • マスターの中央管理のためコミットにrefsを付けないと個人のコミットが ほぼ状況が負えない。(グラフ表示がない) • リポジトリのmaster用とdevelop用で取りまとめがProgrammerとInfraで 別れていたため全く知らないInfra or PMがたまにmerge地獄に会う • プロジェクト・機能・チケット毎にブランチを切っていたら100以上のブ ランチ • デプロイ出来る人が限られてる
  10. 10. My team is slow…!? • Speeeed? • Mergeにすごく時間がかかり、どんどん差分が開く • deployやサーバーの運用をいちいち依頼するのが手間 • commitミスすると、みんなに連絡して∼revertして∼のコスト • Traditional? • GitHubより流れがGitになっていた
  11. 11. Why Modern?
  12. 12. 選択する上で大事にしたこと • イラッとする部分を解決したい • ワクワクする • 世の中を見るとその方がお作法っぽい • プロダクト(プロジェクト)毎に最新を挑戦
  13. 13. install Gitlab • 各々GitHubのアカウント作成し、プライベートでgitを始め る • 無料でサクッと試すためにまずはGitlabを入れた • 突然の英語環境に困惑するもgitになれるため何度もペアオ ペ • 当時Pull Requestの良さ知らず、今までのやり方をそのまま
  14. 14. HikiTrac Subversion Staging Programmer Infra or PM Build 2012~ Gitlab cap deploy
  15. 15. リモートリポジトリの安定 • 個人でcommitを重ねて行えるようになった • リモートリポジトリを壊す心配が減った • 挑戦して満たされるエンジニア心 • しかし、運用がそのままなので、gitに詳しく なっただけだった
  16. 16. install ALMinium • 当時Gitlabのissueだとtracに比べ、見難い • サーバーの突然の死もあったことで、改めて RedmineとJenkins同封のALMiniumをGitリポ ジトリで利用することにした
  17. 17. HikiTrac Subversion Staging Programmer Infra or PM Build 2013~ ALMinum jenkins buildcap deploy
  18. 18. システムの統一 • wikiとticketとソースがひとつになった(wikiとticketの横断検索 は便利) • お手製のビルドサーバーからJenkins導入(しかし使う人は同じ) • Redmineもtracと同じ運用可能(ticket一覧画面で自身専用にカ スタマイズできるのが良かった) • リポジトリのグラフ化で視覚的にわかりやすくなった
  19. 19. 残り課題 • 大量のブランチがあると見難い • ビルド職人の属人化 • Merge地獄
  20. 20. Pull Request and ChatOps
  21. 21. githubkaigi.org • Pull Requestの凄さを知る • hubot によるChatOpsを知る • 同じように課題持っていることを知る
  22. 22. Pull Request ※1 rebaseすることで、Pull Requestの際に自身のcommitのみだけ表示される local remote master remote fork remote master upstream merge git push origin pull request git rebase※1
  23. 23. Pull Requestのお作法 • WIP(Work in Progress) • マージ出来る状態でPull Requestを送る • マージ前にコードレビュー • masterはいつでもデプロイ可能 • 自分の作業コミットだけする(rebaseする) • 終わったブランチはdeleteする
  24. 24. ChatOps • Chat機能を持つコミュニケーションツールとHubotを利用して運用に関わ る様々なタスクを自動化 • 何が起こっているのか、関係者全員が把握しやすい • 複雑な構成のシステムや開発構成でも情報、操作を一箇所に集約できる • ビルド通知をChat上にする • ビルド指示をhubotに指示 • hubotの投稿をデスクトップ通知にして把握
  25. 25. (再掲載)残りの課題 • ブランチの増殖 • ビルド職人の属人化 • Merge地獄
  26. 26. private? • GitBucket • ver3.1 Jenkins pull-request builder可能 • kandan(~2015/06) • lets-chat(2015/07~)
  27. 27. Hiki Trac Subversion Staging Programmer Infra or PM Chat cap deploy ALMinum @hubot jenkins build app 2015/07~入替 2014~
  28. 28. プロジェクトを超えたビルドの確認 ※ kandanから切り替えた理由は、アプリが軽い、最近作られたためメンテが早い、独自のemojiが 使える、デスクトップ通知がある、一画面の情報量が多い、Heroku buttonで試しやすいetc… 通知をマークで表すとわかりやすい 青色マークでわかりやすいビルド青色マークでわかりやすいビルド@hubotからビルドを指示 プロジェクトを超えたビルドの確認
  29. 29. 結果 • ブランチの激減!! • ビルドが誰でもできる! • Merge地獄が0になった!
  30. 30. TIMTOWTDI and BSCINABTE
  31. 31. 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手動?
  32. 32. BSCINABTE • “But Sometimes Consistency Is Not A Bad Thing Either” Bicarbonate • 時には共通のやり方があってもそれは悪いことで はない • 共通のやり方=ChatOps • 複数の環境に対して通知とビルドを共通のやり方
  33. 33. Conclusions
  34. 34. Conclusions • 解決したいものを定義した上で挑戦すると失敗しにくい(初回の Gitlabの運用失敗経験が良かった) • やってみないとわからないことが多いので、まずやってみる • 正しいと思う/ワクワクするかどうかも重要 • TIMTOWTDI and BSCINABTEの考え方で作るとチームにそこま で混乱は起きなかった • "Better late than never "- 「遅く来てもやらないよりまし」
  35. 35. 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/

×