弁護士ドットコムの ITS/Git 運用ガイドライン

# この記事について

- この記事は、 [弁護士ドットコム Advent Calendar 2019 - Qiita](https://qiita.com/advent-calendar/2019/bengo4com)  の 1 日目の記事になります。
- 初日となる本記事では、弁護士ドットコム株式会社の **ITS (Issue Tracking System, 課題管理システム )/Git 運用のガイドライン**を加筆修正の上、公開します。
    - 当社でも、開発におけるビジネスの優先順位が不明瞭で、見える化されていない時期もありました。
    - 本ガイドラインは、開発に関わる人員が数人から数百人レベルに成長する過程で、都度メンテナンスされてきた当社の知見です。
- 目新しいものはなく手垢のついた内容かもしれませんが、開発現場を改善する一助となれば幸いです。

# ITS 運用ガイドライン

- 当社では、 ITS として [Redmine](http://www.redmine.org/)/[Jira](https://www.atlassian.com/ja/software/jira)/[GitLab Issue](https://docs.gitlab.com/ee/user/project/issues/) などを利用してきました。
- ITS を**頻繁に変更することは好しくありませんし、どれを使ってもそれなりの運用はできる**と思います。
- 本件において唯一得た学びとしては、フルマネージドサービスを利用すべきだということです。
- 保守運用や局所最適などの負荷から開放され、本来注力すべき開発に集中することができます。

## 目的

- 基本的に**「個人依頼」**ではなく、**「チーム共有」**する文化を育み、以下 3 つを実現したい
    1. 共有されないことによるリスクの低減
        - 別施策とバッティングして、想定外のバグを発生してしまう
    2. 依頼を受けた人の共有するコストを削減
        - 「〇〇さんに DM したよー。」「聞いてないよー。」
    3. 複数人でフォローできる体制で属人化を防止
        - 「今日は私はお休みです。明日以降で対応します。」
- これらは **ITS を利用しなくても実現できる**が、チケット駆動開発を推奨することで見える化に繋げた
- また、情報整理や対話のきっかけとして、チケットのテンプレートも用意している

## チケットテンプレートとは

- 大きく分けて、バグ（不具合）とストーリー（それ以外）、 2 種類のテンプレートを用意している
- **テンプレートはあくまでガイドライン**なので、全項目を埋める必要はない
    - 軽微な変更や、該当しない項目は空欄可
- テンプレートを無視しても問題ない
    - 詳細な企画書を添付する、あるいはもっと良い書き方があれば柔軟に変更可

### バグテンプレート

```markdown

# 概要

- xxx

# 発生環境

- 端末/OS/ブラウザなど
- バグが発生した日付・時間

# 再現手順

- どのURLから、どのリンクをクリックしたか・どんな値を設定したかなど具体的に

# 期待した結果

-

# 実際の結果

- xxx

# 備考

- スクリーンショットや補足があれば
```

### ストーリーテンプレート

```markdown
# 概要

- 「誰の」ためのストーリーか
- 「何を」したいのか
- 「なぜ」そうしたいのか

# 背景/目的

- xxx

# 受け入れ基準

- 「これが実現していれば目的は達成できる」という基準

# 対象デバイス

- PC
- SP

# 備考

- スクリーンショットや補足があれば
```

# Git 運用ガイドライン

- 当社では、ソースコード管理サービスは GitLab を利用しています。
- GitLab は、 GitHub と類似の機能を無料で使えることから、当社も自分たちで運用（ Self-Managed ）していますが、そもそも**設計思想が異なります**。
- 本件において唯一得た学びとしては、フルマネージドサービスを利用すべきだということです。
- 保守運用や局所最適などの負荷から開放され、本来注力すべき開発に集中することができます。

## 必ずブランチを切ってからコミットする

- no branch, no commit. no ticket, no branch.

### 目的

- コミット履歴を ITS に確実に紐付けること
- レビューのための下準備

### 概要

- ブランチ名は `feature/1234/hoge-fuga-piyo` のように `[ブランチ種別]/[ITS ID]/[ブランチ内容]` で入力
    - ブランチ名の重複を避けるために命名規則を定義

#### ブランチ種別 

- `feature` : 機能開発
- `hotfix` : バグ修正
- `develop` : 機能統合
    - 大きな開発の際に用意してもよい（通常は不要）
        - `develop` から `feature` を切って、`develop` に対してマージする（レビュー必須）
        - master と乖離しないように、定期的に `rebase master` する

#### ITS ID 

- チケット駆動開発を推奨
- チケットを切らない場合、コミットメッセージに必ず変更理由が分かる詳細を書くこと

#### ブランチ内容 

- 好きに入力
    - キャメルケースは同名で大文字小文字異なると問題となることがあるので、小文字ケバブケース統一を推奨
        - ちなみに、わたしはケバブケースではなく[おでんケース（ oden-case ）推奨論者](https://twitter.com/hir0n0r1/status/1151383739517157381)
- 禁止事項 
    - master への直コミット禁止

## master ブランチへのマージはレビュー必須

### 目的

- 必ずレビューを通すことで、ミスを防ぐ
- 業務知識の共有を行うことで、属人化を防止

### 概要

- GitLab 上でのマージリクエストでレビューを通してから master ブランチにマージ 
    - 例外は上長承認が必要
        - 運用しながら事例ベースでルールを作っていく
    - マージリクエストには最低限 ITS URL を記載する

## マージリクエストはレビュー依頼者がマージする

#### 目的

- レビュー依頼者がマージ後も確実に動作することに責任を持つ
    - `rebase` や `merge` 時のコンフリクト解消も責務

### 概要

- レビュー依頼を受けた側は、問題なければ以下の様なコメントを残す 
    - LGTM
    - :+1:
- 問題はないけど、意味のある粒度でコミットをまとめたほうがよい場合は、その旨指摘する
    - 「意味のある粒度」とは、文末に貼っている [Git Style Guide の Commits の項](https://github.com/agis/git-style-guide#commits) を参考にしている
- レビューが通ったマージリクエストは、レビュー依頼者がマージする 

## ボールを持っている人を `Assignee` にする

### 目的

- アクションし終わったら都度 `Assignee` を変更することで、誰がボールを持っているか明示する

### 概要

- レビューを依頼する時 → レビュアーを `Assignee` に
- レビューし終わった時 → レビュイーを `Assignee` に
- LGTM を出した時 → レビュイーを `Assignee` に (マージするため)
- `Assignee` は「レビューを放置しない」ことに責任を持つ
- 余りに細かいもの (簡単な質問のやりとりなど) は `Assignee` を変更しなくともよいが、その場合でも `Assignee` になっている人が責任を持ってコミュニケーションを取ること

# 参考

- [agis/git-style-guide: A Git Style Guide](https://github.com/agis/git-style-guide)
- [github - Git branch name - case sensitive or insensitive? - Stack Overflow](https://stackoverflow.com/questions/38493543/git-branch-name-case-sensitive-or-insensitive)

# 最後に

- 弁護士ドットコムに私は 5 年以上いますが、今が一番面白い時期にきていると思います。
- **雇用形態問わず**、「一枚噛みたい」という方や「ちょっと見てみたい」という方は、積極採用中ですのでぜひご連絡ください。