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

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

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