CodeIQ MAGAZINECodeIQ MAGAZINE

GitHub FlowでShip it! 「今からバグを直してリリースっスか?カタカタカタッ。ポチッとな。終わったっス。」 #git #github

2014.11.27 Category:技術コラム Tag:

  • 12
  • このエントリーをはてなブックマークに追加

Gitリポジトリのブランチ戦略で悩むことはありませんか?

今回は、Git・GitHubを利用したシンプルで強力なワークフロー「GitHub Flow」について詳しく解説します。
by tbpgr

はじめに

こんにちは。出題者のtbpgrです。

当記事はGitHub Flowに関する記事です。
以下の構成になっております。

  1. GitHub Flow とは?
  2. GitHub Flow 図解
  3. GitHub Flow のメリット
  4. GitHub Flow の制約
  5. 現場比較
    1. 由緒正しき手の温もりあふれるデプロイフローの現場
    2. GitHub Flowの現場
  6. 代替手段

前提として、 Gitの知識が必要になります。

GitHub Flow とは?

GitHub FlowはGit・GitHubを利用したシンプルで強力なワークフローです。
Gitでは、集中型のリポジトリと比べて頻繁にブランチの作成、マージを行います。
決められたワークフローに従うことで、ブランチの運用が容易になります。

git flow と GitHub Flow

Gitを利用したワークフローの中では、git-flowが有名ですが、
ブランチ戦略が複雑で、導入コストがやや高いです。
必ずしも全てのプロジェクトが、git-flowほど複雑なワークフローを必要とするわけではありません。

そこで、GitHub Flowの出番です。

GitHub Flow の基本原則

  • masterブランチは、常時デプロイ可能である
  • 機能追加、バグフィックスなどは 説明的な名前のブランチをmasterから作成する
    • 機能追加の例:add_user_notice(ユーザーの通知機能追加)
    • バグフィックスの例:fix_user_login_validation_error(ユーザーのログイン認証のVlidation修正)
  • 作成したブランチでローカル開発。小さい単位でこまめにコミットし、リモートにもこまめにPush
  • フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、Pull Requestを作成する
    • フィードバックや助言が欲しい時に作成するPull RequestをWIP Pull Requestという
    • WIP = Work In Progress
    • WIP Pull Requestを行う場合は、Pull Request名の頭に [WIP] をつけるのが慣習
  • レビューOKになったら、masterへマージ
  • masterへpushしたら、即デプロイをする

GitHub Flow 図解

※クリックで拡大表示

上記の図は、無償UMLモデリングツールの astah* community で作成されています。
私のGitHubリポジトリ(github_flow_for_ja)に、
astah* community の編集元ファイルを置いてありますので、組織内のワークフローに合わせて
ワークフローをカスタマイズしたい場合などは、フォークしてご活用ください。

また、 GUI による描画が億劫。RubyのDSLで図を作成したい、という方には
Gviz gem ( 内部で Graphviz を利用します ) で作成した図も下記にあります。
こちらもカスタマイズして利用したい場合には、フォークしてご活用ください。

Gviz を利用した GitHub Flow図
Gviz を利用した GitHub Flow図のソースコード

GitHub Flow のメリット

  • シンプルなので、すぐに覚えることができる
  • シンプルなので、日々の開発において考えなければならないことが減る
  • 孫ブランチを作らないので、あちこちのブランチにマージ、などの難しいオペレーションが発生しにくい
  • Pull Request 、マージの過程にコードレビューが組み込まれている
  • 開発中のフィーチャーのみが、トピックブランチにあるため仕掛り作業が把握しやすい
    • トピックブランチの説明的な命名が活きる
  • master ブランチの内容はいつでもリリース可能
    • ビジネスのスピードを上げる
      • 顧客の要求変化が激しい分野
      • スタートアップ企業
    • 技術的負債返済の敷居を下げる

GitHub Flow の制約

  • 開発者全員がトピックブランチに適切な命名を行うことができるレベルが求められる
    • 「名前をつけるのはプログラマの仕事じゃない」というレベルの現場もある
  • 自動テスト、GitHub、デプロイツールなどフロー全体を回すための開発基盤を整備する開発者が必要
  • より複雑なリリース戦略が必要なプロダクトの場合には適用できない
  • スマートフォンアプリなど、即リリースできないケースには向かない

現場比較:由緒正しき手の温もり溢れるデプロイフローの現場

今でもこんなリリースフローを適用している現場があります。

リリース準備フェーズ

  • リリース向けにブランチを作成して開発開始
  • 軽微な修正でも2週間以上前に開発を凍結する
    • 組織内のリリース判定に時間がかかる
      • 承認印の待ち行列
    • リリース準備に時間がかかる
      • 自動テストが完備されていないため、退行テストのコストが高い
      • 毎回リリースフローが変わる
        • 影響範囲を局所化したいらしい
      • リリース時に行う UNIX のコマンド操作を1コマンドずつ Excel に記述する手順書
        • なぜか自動化は許さない。手の温もりなら信頼できるらしい
        • cd したら pwd 必須
        • Excel の手順書イメージ
コマンド 説明
cd ~/ ホームディレクトリに移動
pwd ディレクトリの確認
mkdir deploy デプロイ用ディレクトリの作成
: :
延々と続く手順

リリース作業

  • 1コマンドずつ手動で実行するので時間がかかる
  • 手順が多く、手動のため高確率でリリースミスが発生する
    • 人はミスをするもの
  • リリース不備があった場合のロールバック手順も手動で1コマンドずつ

由緒正しき手の温もり溢れるリリースの弊害

  • リリースコストが高いので、すぐに直せる内容でも一定量のリリース対象が揃うまでリリースを待つ
  • リリース待ちの期間が長すぎて他のバグや追記機能など、同時に開発が進むブランチが増える
  • リリース対象のサーバーが増えるとリリースの手間が増台
  • ブランチが大量になり、ブランチ間の整合性維持のコストが増台。マージミスの可能性が上がる。
  • リリース待ちのタスクが増え、タスクの管理コストの増台
  • 緊急度の高いリリース時に、退行テストの一部が省略され、障害発生の可能性が上がる

現場比較:GitHub Flowの現場

リリース準備フェーズ

  • トピックブランチを作成して開発開始
  • 開発凍結からリリースまでの期間が短い
    • リリース手順は変わらないので毎回手順書を作成する必要はない
  • トピックブランチの開発が終わったらプルリクエストを作成
  • プルリクエスト時に自動で退行テストが実行される
  • プルリクエストの内容をレビューし、問題がなければ master にマージ

リリース作業

  • プルリクエストを master にマージした段階で自動的にデプロイされる

代替手段

GitHub Flow を利用したいが、

  • クラウドの利用許可がでない
  • 予算を確保できない

などの事情で GitHub を利用できない場合、
Bitbucket・GitLabで代用することができます。

  • Bitbucket
    • 5userまでならリポジトリ無制限・無料利用が可能
    • Atlassian社の他ツールとの親和性が高い
  • GitLab
    • Private な環境にインストール可能(クラウド版もあり)
    • GitHubクローンなので基本的な操作は GitHub と酷似している

まとめ

GitHub Flow いかがでしたでしょうか?
普段 git を利用していて、シンプルなワークフローとビジネスのスピードを必要としているなら
導入を検討してみてください。

参照

CodeIQ運営事務局より

tbpgrさんより、GitHubに関する問題を掲載中です。
ぜひチャレンジして、GitHubに親しんでみてください。

  • 問題挑戦はこちらから→ GitHub入門
  • 挑戦受付締切:2014年12月16日 AM10:00

  • 12
  • このエントリーをはてなブックマークに追加

■この記事を書いた人

avatar

tbpgr

CodeIQでRubyや様々なカテゴリの問題を出題中。 Twitter:@tbpgr Tbpgr Personal Page: http://tbpgr.github.io/

■関連記事

Fix typo駆動でOSSに貢献する。RubyへのFix Typo Pull Requestの実演... システム開発の仕事と切っても切り離せないOSS 昨今の開発において多くの人がOSSの恩恵を受けています。 そして、GitHubの登場により普段利用している「あのソフトウェア」に 貢献することも大きな障壁ではなくなりました。 OSSに対する貢献は強制されるようなものではないものの、 「私にもできる...

今週のPickUPレポート

新着記事

週間ランキング

CodeIQとは

CodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。

CodeIQご利用にあたって
関連サイト
codeiq

リクルートグループサイトへ