1. Gitの運用

以前は社内のSubversion又はGitLabを使ってコード管理を行っていましたが、以下の理由から本プロジェクトはGitHubを利用してみたい！という思いが高まりました。

外部サービスとの連携が行える
- CircleCI、CodeDeploy、Slack通知など
- BitBucketも候補に上がったが、連携先の観点からGitHubに対象が絞られた
サーバの運用を任せられる
バージョンアップを自動で行ってくれる
オープンソース界隈ではGitHub使うのがメジャーなので使ってみたかった

しかし弊社ではGitHubの利用は公式には認められていなかったのですが、情報セキュリティに関するルールとかをちゃんと押さえつつ、社内調整を経て、GitHubを使えるようになりました(^0^)/ ※会社によって諸事情ありますよね (^^;

1.1. 運用ルール(一部抜粋)

プライベートリポジトリのみ利用可能
Organizaiton利用必須
- Organizaitonを利用しオーナーを一人定める
  - 誤操作防止と監査の観点から情シスのアカウントをオーナーに
- 監査ログは社内のみの利用とする
  - オーナーしか参照できない
GitHubの一般公開リスク対応について
- 誤操作防止
  - 通常業務で利用しない社員をオーナーとすることで誤操作防止のリスクを低減させる
- 誤操作検知
  - 該当リポジトリに外部からアクセスできるかを監視する処理を監視サーバーに設定
クリーニングプロセス (AWS不正利用防止)
- 開発マシンにgit-secrets (AWSの認証情報を誤ってリポジトリに登録することを防止するソフト) を必ずインストールする
GitHubのアクセスコントロールについて
- 社用PC以外での利用防止
- 利用アカウントは必ず2段階認証を設定する
- 1ユーザ1SSHキーとする
- 月次の棚卸しで確認する

今では、チームメンバーがリモートワークをするようになり、場所に縛られず開発を行う観点でも恩恵を受けています。

もともとgithubにIssue管理があるのですが、そのままでは運用するのが色々辛かったです。しかし、運用ルールを設けることで改善されて、今はIssue管理はGitHubに統一しています。

ラベルを活用して一覧からチケットを把握できるようにした
- 状態管理：「仕様確認」、「確認待ち」
- 種別管理：「バグ」、「改善」、「セキュリティ」、「TODO」
- 対象管理：「フロント」、「バックエンド」、「管理画面」
- 優先順位：「優先度低」、「至急」
マイルストーンを設けて直近に取り掛かるべきチケットにフォーカスする
- リリース対象をまとめるのにも利用
プロジェクト
- プロジェクトは短い期間のタスク管理に利用
- TODO, DOING, CHECKING, DONEの看板を用意して運営
検索
- 担当や期間が割当たってないIssueを定期的にチェック
- no:assignee, no:milestone
コミットのコメントはIssue番号を載せて Issueと関連付ける
- 例： Issue #123 管理画面にアカウント参照機能の追加
他の人に確認してほしい時は、メンションを利用
Slack連携を行い、プロジェクトの動きを把握