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

7463 ワード
Redmine GitHub jira GitLab Git 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

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

ブランチ内容

  • 好きに入力
    • キャメルケースは同名で大文字小文字異なると問題となることがあるので、小文字ケバブケース統一を推奨
  • 禁止事項
    • master への直コミット禁止

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

目的

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

概要

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

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

目的

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

概要

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

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

目的

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

概要

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

参考

最後に

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