読者です 読者をやめる 読者になる 読者になる

Rails Webook

自社のECを開発している会社で働いています。Rails情報やサービスを成長させる方法を書いていきます

GitHubを使った今時のWebアプリ/システム開発の流れ

Git/GitHub チーム

GitHubを使った今時(2014年頃)のWebアプリ/システム開発の流れを説明します。
Webアプリケーション、スマホアプリ/スマホゲームを開発している会社では、「アジャイル開発」が主流となっています。ユーザーの反応を見て、機能追加やバグ改修を行い、商用環境に数日、1週間でリリースするといったスピード感で開発するために「GitHubを使った開発フロー」が行われています。


※必ずしもGitHubを使わなくても良いですが、多くの会社はGitHubやその類いのツールやサービスを使っています。


目次

  1. 開発フローの背景
  2. 会社内で開発する開発フロー(on GitHub)
  3. オマケ:OSSに貢献する開発フローメモ(on GitHub)


1. 開発フローの背景

従来からある開発方法論である「ウォーターフォールモデル」では、

  • 1,2年開発している間にビジネス環境が変わってしまったため、システム要件がビジネス要件に適合しなくなった。
  • 完成するまでユーザー/発注者がシステムを実際に動かさないので、ユーザー/発注者が想像してたものと開発されたものが違う。

など「ユーザーにとって役に立たない(=価値のない)システムを作成する可能性が高い」という欠点がありました。


そこで、昨今ではWeb業界やスマホアプリやゲームを作っている会社では「アジャイル開発」で開発しています。厳密なアジャイル開発で実施していなくても以下のようなエッセンスを取り入れています。

  • 現状のWebアプリケーションやシステムの利用状況から改善項目やバグ改修などのタスクを洗い出して、優先度をつける
  • タスクを優先度順に、チームメンバーに割り振って「イテレーション単位(1週間などの設計からリリースまでの期間)」で実施

これを繰り返していくことで、実際のユーザーの声(利用状況やアンケートなど)を反映し、
「ユーザーにとって役立つWebアプリケーションやシステムを開発すること」ができます。


※アジャイル開発は、チーム内でプロダクトの方向性を決め、実装し、リリースするということが短期間で行われるのでコミュニケーションが多発します。そのため、受発注関係のSIer業界ではスピード感を実施しづらい開発方法です。


※ウォーターフォール開発自体を否定しているわけではありません。
実際、BtoCの会社では、エンドユーザーに見せられるレベルまでをウォーターフォールで開発しリリースし、その後、ユーザーの利用状況を確認しながら、追加機能やバグ改修をアジャイル開発で実施して、柔軟にユーザーの満足度をあげて、サービスをグロースさせている企業もあります。


2. 会社内で開発する開発フロー(on GitHub)

シンプルなので学習コストが低く、実施コストも低く、小さな変更もすばやく柔軟に対処できるGitHub社自身も実施している開発フロー。

0. 前提条件

masterブランチは常にデプロイできる状態しておく

masterブランチは常にデプロイできるということは、大きなバグなどがない安定したソースであるということ(小さなバグはあるかも)
そのため、いつでも機能追加やバグ改修などのブランチを作成できるようになります。これは、つまり、複数人での並行開発のベースとなります。

デプロイをコマンド一発でできるように自動化する

デプロイツールを利用して、コマンド一発でソースコードを商用環境にデプロイできるようにしておき、人的ミスをなくしましょう。
デプロイツールには、ロールバック機能もついているものもあるので、前のバージョンに戻すことも簡単にできます。

CIツールにより、テストの作成とテストの自動実行をする

全てのソースコードにはテストコードを書きます。(テスト駆動開発で開発することを推奨)
リモートリポジトリにpushすると、CIツールにより自動的にすべてのテストを実行できるようにしておきましょう。
クックパッド社では、17000件のテスト項目を60並列程度の分散処理で行い、平均8-9分で実施
http://techlife.cookpad.com/entry/2014/03/24/rrrspec/から引用
GitHub社では、14,000件のテスト項目を3.5分程度で実施
https://speakerdeck.com/holman/how-github-worksから引用

ステージング環境(本番環境を再現した環境)を用意する

クリティカルな部分に影響を与えるような大きな変更などを加えたときに手動でテストするために、本番環境にデプロイする前に動作を確認できるようにします。
もちろん、ステージング環境へのデプロイもコマンド一発でデプロイしておくようにしておいてください。
タイポ(誤字脱字)など細かなレベルであればこの環境を使わず商用に直接デプロイしても良いと思います。

1. コマンドラインでローカルにソースをコピーする

$ git clone "リポジトリのURL (例:https://github.com/rails/rails.git)"

2. 新しい作業をするときは、masterブランチから記述的な名前のブランチを作成する

まず、masterブランチを最新の状態にする

$ git co master
$ git pull

そして、トピックブランチを作成し、GitHubのリポートリポジトリにpushする

$ git co -b "トピックブランチ名"
$ git push orign "トピックブランチ名"

開発者が何をしているか想像できる具体的な名前が良い。
(例:user-content-cache-keysubmodules-init-taskredis2-transitionなど)
こうすることにより、リモートリポジトリのブランチ一覧を確認すれば、チームがどんなタスクをやっているか明確。
機能や要件が、トピックブランチになり、それが、PR(ソースコードレビュー)に対応するので、ソースコードレビューをしてもらいやすくするために、機能や要件を細かくし、トピックブランチも数日や1週間など短期間で開発できるぐらいの粒度にしましょう。

3. ソースコードを記述する

こまめにコミットして、ソースコードレビューをしやすいようにする。
コミットの粒度はチームで合わせておくことで、それぞれがソースコードレビューをしやすくなります。

$ git add .
$ git ci -m "コミットメッセージを記載"
$ git push -u origin "トピックブランチ名"

テスト駆動開発の流れで実施する場合、

  1. テストコードを記載する
  2. そのテストが通るようにソースコードを実装する
  3. テストが通ったらリファクタリングし、リファクタリング後にテストが成功することを確認し、
  4. リモートリポジトリにソースをpushする。

4. Pull Requestを作成し、Pull Requestでやりとりする

上記の"3"の作業は、PRにWIP(Work In Progress:作業途中)をタイトルにつけて、フィードバックをえながら開発する。
コメント内に「@ユーザ名」と入力すれば、そのユーザにNotificationsが飛ぶ。
いつPRを作成するかはチームで決める。


問題が複数あり、指摘と修正を何度も繰り返しmasterブランチへなかなかマージされない状況がたまにあります。
それは、コミュニケーション不足の場合は、直接顔を合わせて話し合う。
また、技術力や能力の不足野場合は、コーディングルールの整備と周知、開発上のルールはwikiなどでまとめ、開発者のスキルをあげるために勉強会や書籍などで知識の共有、ペアプログラミングなどを実施し、「レビューをすんなり通り、すぐにマージできる品質でコードを書き上げれるレベル」までもっていく。

5. ほかの開発者がレビューする。

全てのソースコードは他の誰かがレビューをした状態にする。
:+1:+1LGTM(Looks good to me=良いと思う)などの同意を得る。

6. 作業終了を確認したらmasterブランチにマージする

「2,3人以上がレビューし、その結果+1などのコメントが2,3個以上存在したらPRを行った開発者がmasterブランチにマージできる」などmasterブランチに「マージする人」、「マージするタイミング」はチームで決める必要があります。

$ rebase -i HEAD~3  # 3つのコミットをまとめる。基本はpick1つ、その他はfixupで過去のコミット1つにまとめる
$ git push

その後、GitHubのプルリクエスト画面で緑色のマージリクエストボタンを押して、マージリクエストをする。

7. masterブランチへマージしたら、すぐにデプロイする

誰かが(自動で)マージを取り込まれると、CIにより自動テストが自動実行され、それがパスしたらコマンド一発でデプロイして下さい。
もし、大人数・複数チームで並行で開発していて本番環境へのデプロイが並行する可能性がある場合は、チームでのデプロイルールを整備する必要があります。


3. オマケ:OSSに貢献する開発フローメモ(on GitHub)

1. GitHub上でOSSソースをForkする
2. コマンドラインローカルにソースをコピーする($ git clone)
3. トピックブランチを作成する($ git checkout -b "トピックブランチ名")

・OSSが英語なら、トピックブランチ名やコミットメッセージは英語で記載する
・トピックブランチ名は、変更内容を端的に表した名前にする

4. トピックブランチに対してコードを変更し、コミットする

・Pull Request(以下、PR)でソースコードレビューしやすいように細かくコミットする

5. トピックブランチをリポジトリにpushする($ git push -u origin "トピックブランチ名")
6. GitHubでFork元に対してPRを作成して送る
7. PR上でやり取りして、コミット権限がある人にソースを取り入れてもらう(mergeしてもらう)

参考文献

  • git, github, 開発フローなど基本から分かりやすく説明されているのでgit, github初心者は一読する価値があります。

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

以上です。
よく分からない箇所や、間違いがありましたらコメントください。