Git & GitHub & kintone でウルトラハッピー!

38,737 views
41,154 views

Published on

ブログで補足してます: http://developer.cybozu.co.jp/tech/?p=919
cybozu.com インフラ開発・運用チームのソースコード管理システムを Subversion & Fisheye + Crucible から Git & GitHub & kintone に変えるまでのお話です。

Published in: Technology
0 Comments
32 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
38,737
On SlideShare
0
From Embeds
0
Number of Embeds
31,426
Actions
Shares
0
Downloads
56
Comments
0
Likes
32
Embeds 0
No embeds

No notes for slide

Git & GitHub & kintone でウルトラハッピー!

  1. 1. Git & GitHub & kintone で ウルトラハッピー! サイボウズ株式会社 山本泰宇 @ymmt2005 © 2012 Cybozu. All rights reserved.
  2. 2. どんな人にうれしい話?ブランチ管理が地獄のよう • Git なら素早く解決! だと悩んでいる人 • ブランチ & マージは日常作業になりますFisheye® + Crucible® • GitHub は速いしメンテナンスも楽々 に悩んでいる人Git やってみたいけど、きっ • Hazama のノウハウ集、共有します! かけがつかめない人 ※Fisheye, Atlassian Crucible は Atlassian の商標です ※Hazama は cybozu.com のインフラツール開発チームです
  3. 3. cybozu.com 運用管理ツール • ストレージ管理データセンター用 • VM管理 • 各種モニタリング • 深刻な問題が発生すれば即改修が必要頻繁なリリース • 依存関係の都合でリリース期日指定も良くある • 開発環境(試験用) 環境が二つ • 運用環境(試験済み)
  4. 4. 開発の流れ 開発DCでQA試験•設計レビュー •試験済み、かつ•実装レビュー&修正 •開発環境用に結合 •リリース可のコードを適用 •バグが混じり、不安定 •週に何回も適用することも •検出不具合を追加修正 各自開発 運用DCに適用
  5. 5. Subversion時代: 不幸のどん底• trunk に直接コミット • ブランチ作成は遅すぎて滅多にしない (作った後のチェックアウトが遅い)• 安定版を作るには 1. ブランチを作成 2. 未試験のコミットをリバースマージ• 問題点 • コミットログの精査が人力 • 後回しにすると、ますます辛い• 安定版ブランチを持つ? • 目でログを探す点は変わらない • マージしていないコミットの管理が辛い
  6. 6. 解決したい問題ブランチ作成の高速化 • 個々のタスクごとにブランチを作成したい(トピックブランチ) • 一度マージした後、追加の改修を再度マージマージを繰り返したい • 親ブランチの変更を取り込み後、親ブランチに再度マージ • まだマージしていないコミットを自動検出したいマージを楽にしたい • 特定のコミットをすばやくマージしたいSubversion が遅い • 日々のストレスにもう耐えられません
  7. 7. Gitで解決! その理由手元にレポジトリ • ブランチ作成やマージはすべてローカル操作 が丸ごとある • だから高速!リモートレポジトリ • 日々の作業は極めて高速 とは差分更新 • 初回のクローンだけ遅いコミット履歴は • Git のブランチ=分岐したグラフの枝 グラフ管理 • Git のマージ=二つの枝の合流
  8. 8. Git vs. MercurialGit のほうが強力で、速くて、省スペースで、難しい• 慣れれば Git の利点が大きいGitHub が便利すぎる• これから解説します Linux カーネルとその周辺が Git 管理• Hazama は良く Linux の不具合追うので…というのは私だけの意見じゃないですよ!• Why did Git get so much hype? …while others dont?• Git, Mercurial and Bazaar – A Comparison
  9. 9. GitHub Enterprise Git だけでサイボウズの開発はまわらない • コードレビューどうする? • レポジトリ管理・アクセスコントロールは? • 共有レポジトリは誰が管理するの? そこで GitHub Enterprise • github.com を仮想アプライアンスで社内運用 • 1ユーザー年間2万円くらい
  10. 10. GitHub いいよ!• GitHub = Gitレポジトリ管理 + レビューツール • ユーザーが自由にレポジトリを作れる! • Fisheye® + Atlassian Crucible® より速い • Fisheye® + Atlassian Crucible® より落ちない • Fisheye® + Atlassian Crucible® よりメンテナンスが楽 • おまけに Wiki と Gist もついてくる• Wiki 便利 • Gitレポジトリになっているので、テキストエディタで編集が可能 • 編集がコンフリクトしてもうまくマージできるよ • Issues はしょぼい • kintone と連携すれば最強 ※kintone は cybozu.com のアプリ作成ツール Hazama の開発タスク管理にも使っています
  11. 11. PULLリクエスト駆動開発• PULLリクエスト • レビュー&マージツール • よそのプロジェクトにパッチ投げることもできる • レビュー OK ならボタン一発でブランチをマージ • 死ぬほど便利なので、PULLリクエスト中心にワークフローは考えよう!• ワークフローの例 ここが肝 1. タスクごとにトピックブランチを作る 2. PULLリクエストを投げてレビューしてもらう 3. 指摘事項を修正してトピックブランチにPUSH 4. PULLリクエストの中身が更新されるので、再レビュー 5. レビューOKならレビュワーがボタンクリックでマージ&クローズ!
  12. 12. 導入後のワークフロー PULLリクエスト 開発レポジトリ PULLリクエスト 安定レポジトリ トピックブランチ hazama/infra forest/infra 開発DCでQA試験•設計レビュー •試験済み、かつ•実装レビュー&修正w •開発環境用に結合 •リリース可のコードを適用 •バグが混じり、不安定 •週に何回も適用することも •検出不具合を追加修正 各自開発 運用DCに適用
  13. 13. 言うは易しだが・・・ • hazama/infra は Hazama 開発チーム管理管理権限を分離 • forest/infra は運用チーム管理二つのレポジトリを • 試験が終わるまでは hazama/infra にマージ意識する必要あり • 試験終了後は forest/infra にマージ開発完了の順に • リリースするべきものだけを chrry-pick • うまくやらないと、意図しない hazama のコミットが紛れ込む試験完了はしない • トピックブランチから必要なコミットを自動的に抜き出したい
  14. 14. 行うは難し $ git clone github:hazama/infra管理権限を分離 $ git remote add stable github:forest/infra $ git fetch stable二つのレポジトリを $ git fetch origin $ git checkout –b INFRA-xx origin/master意識する必要あり $ git push origin INFRA-xx $ git fetch stable開発完了の順に $ git checkout –b INFRA-xx-forest stable/master $ git fetch origin $ BRANCH_ORIG=$(複雑なコマンド)試験完了はしない $ git cherry-pick --first-parent --no-merges $BRANCH_ORIG..origin/INFRA-xx $ (コンフリクト修正) $ git push origin INFRA-xx-forest
  15. 15. hazama tools でウルトラハッピー!git-hazama 拡張コマンドkintone API クライアントgithub v3 API クライアントgithub-kintone 連携 Chrome 拡張 GitHub で公開してます! https://github.com/ymmt2005/hazama-tools
  16. 16. git hazama でこうなる! $ git hazama setup infra管理権限を分離 (clone して remote 追加) $ git hazama dev二つのレポジトリを …. $ git hazama review dev TICKET意識する必要あり (トピックブランチ作成, PUSH, PULLリク作成, kintone 更新) $ git hazama pick TICKET開発完了の順に (必要なコミットを自動 cherry-pick) $ git hazama stage TICKET試験完了はしない (forest/infra へのPULLリク作成, kintone 更新)
  17. 17. GitHub ⇔ kintone 連携 ← Chrome 拡張でチケットに自動リンク ↑ git hazama が PULL リク自動記載
  18. 18. Git に乗り換えるには? Hazama謹製 • 要望あれば公開検討します! チュートリアル • @ymmt2005 までどうぞ • git svn のラッパー svn2git • 関連の薄いモジュールのレポジトリは分割インポートがお勧めGitHub アカウント • サインアップしてご自由にどうぞ • 「コミットグラフ」の意味がわかるくらいでないと厳しい一人は慣れていること • 各チーム一人は、隠れ Git ユーザーがいるでしょう 
  19. 19. Good Luck!

×