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

この記事について

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

ITS 運用ガイドライン

• 当社では、 ITS として Redmine/Jira/GitLab Issue などを利用してきました。
• ITS を頻繁に変更することは好しくありませんし、どれを使ってもそれなりの運用はできると思います。
• 本件において唯一得た学びとしては、フルマネージドサービスを利用すべきだということです。
• 保守運用や局所最適などの負荷から開放され、本来注力すべき開発に集中することができます。

目的

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

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

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

バグテンプレート

# 概要

- xxx

# 発生環境

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

# 再現手順

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

# 期待した結果

-

# 実際の結果

- xxx

# 備考

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

ストーリーテンプレート

# 概要

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

# 背景/目的

- 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 ）推奨論者
• 禁止事項
  • master への直コミット禁止

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

目的

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

概要

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

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

目的

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

概要

• レビュー依頼を受けた側は、問題なければ以下の様なコメントを残す
  • LGTM
  • 
• 問題はないけど、意味のある粒度でコミットをまとめたほうがよい場合は、その旨指摘する
  • 「意味のある粒度」とは、文末に貼っている Git Style Guide の Commits の項 を参考にしている
• レビューが通ったマージリクエストは、レビュー依頼者がマージする

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

目的

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

概要

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

参考

• agis/git-style-guide: A Git Style Guide
• github - Git branch name - case sensitive or insensitive? - Stack Overflow

最後に

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