チーム

エンジニア5,6人くらい。

Feature, Story, Task

Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。
Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。
Storyは複数のTaskを持っていて、それぞれのTaskは1,2日で完了する。

たまに1週間くらいのFeatureを割り込みでさくっとリリースすることもあったりする。

ここで言いたかったのは、Featureというものの感じがgit-flowとかとは違いそうダナーって感じてるってところ。

付箋 + Confluence

他部署とのやりとりにはJIRAを使ったりもするけど、チームのタスク管理は付箋でやってる。Featureの内容とか、残しておきたい情報とかはConfluenceで残してる。Feature Pageと呼ばれるページにそのフィーチャーの仕様が書かれている。

Pair Work

ペア開発してる。ペアプロするときもあれば、別々に作業をすることもあるけど、プルリクエストを出すときは、ペアレビュー済みのものが出される。

Pull Request

AtlassianのStashを使ってる。全ての修正はプルリクエストで別のペアからレビューされる必要がある。

ステージング環境

リリース前にはステージング環境でQAを実施する。

こんなところかな。

1 masterからfeatureブランチを作成する

git fetch --prune
git checkout -b feature/weather-news origin/master
git push origin feature/weather-news

Stashのブランチパーミッションを使いたいので、featureブランチ名には"feature/"プレフィックスを付ける。以下のブランチにはpushによる更新ができないように設定する。プルリクエストによる更新のみを受け付ける。

• master
• feature/*

2 featureブランチからstoryブランチを作成する

git fetch --prune
git checkout -b story/weather-news/show-area origin/feature/weather-news
git push origin story/weather-news/show-area 

3 WIPプルリクエストを作成する

git commit --allow-empty -m "Start story"
git push origin story/weather-news/show-area

事前に以下の内容を考えて書いておく。

• ストーリーのタイトル(プルリクエストのタイトル )
  • タイトルには作業中って分かるように"[WIP]"と書いておく
• Feature PageのURL
• ストーリーの概要
• DONEの定義
• このストーリーでやることリスト

4 ローカルではこまめにコミットする

この数年間、何かを調べるときにはコミットログを見ることはあんまりなかった。プルリクエストの方を見る。ので。もう、コミットログは気にしない。自分用メモ的な立ち位置。

5 帰る前にはstoryブランチをリモートにpushする

次の日体調悪くなっても大丈夫なようにね。ペアの人がやってくれるから。

6 storyが完了したらWIPをはずしてレビュアーを追加する

別のペアにお願いする。

7 レビューが完了したらfeatureブランチにマージ

マージされたらstoryブランチは削除

8 そんなことを繰り返していく

そうするとこんな感じでfeatureブランチが進んでいく

9 開発が終わったらステージング環境にデプロイしてQAをする

このブランチ名を指定してステージング環境にデプロイ。QA実施。

10 QAが終わったらmasterに向かってプルリクエストを出す

レビューOKだったらマージ。そしてデプロイする。デプロイするときに自動でタグづけする。featureブランチは役目を終えて削除される。

まとめると

こんな感じが良さそうかなーって思った。チームに聞いてみよっと。

HotFixもBugFixもFeatureと同じ流れでやればいいかなーって。あと、全部のブランチを自動でテスト流したいし、テストがOKだったら、そのブランチ用の環境を自動で作ってデプロイしたいなぁ。