Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Pull request based development

9.920 visualizaciones

Publicado el

July Tech Fest 2015
2015/07/26

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

Publicado en: Tecnología

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/

×