Gitが浸透していない社内に普及させたい(現在進行系)

ITCアドベントカレンダーの記事です。
「射撃教習申請について 他」とか書いてたんですが、結局申請出してないし内容を変えます。

何の記事か

アルバイト先で新しく受注案件が発生したのですが、弊社は

• 手動でソースを管理し
• 作業場所として開発サーバーに 〇〇_kakimoto/のようなディレクトリを作成し
• それまでのソースと目grepをし
• SFTPで直接反映する

という状況のため、かねてよりミスが危惧されていました。
今回、新規に立ち上げであることと、最初期の開発者は自分一人であること、のちのち開発に加わるメンバーもそろそろフローを変えたいと思っていたということでGit/GitHubの導入を決めました。

導入にあたってしたことを備忘録としてまとめましたので記事とします。

要件

1. PHP, MySQLを使った管理ツール
2. なるべく覚えることは少なく
3. それまでのスタイルを大幅には崩さないこと
   4. →つまりLaravel等のフレームワークは学習コストが大きいため避ける

の3点をまず最初に意識しました。2と3は今後社内に普及させることを考えて導入ハードルを下げるために意識します。

セキュリティを担保する

我々が趣味で作るクソみたいなコードと違って、プロダクトとして開発をする以上一定のセキュリティを担保する必要があります。
リモートリポジトリを選定する上で、自社で管理できるGitLabも挙がりましたが、インストールと管理のコストを考え今回は見送りました。
選択肢としては

• GitHub
• GitLab
• Backlog

ぐらいがメジャーかなと思います。
Backlogも良いかなと今となっては思うのですが、個人的に私が使い慣れたGitHubにし、メンバーのうち社員のアカウント内にPrivateリポジトリとして設定することにしました。

その他、GitHubアカウントの乗っ取りも最近起きているということなのでDBへの接続情報なども.gitignoreで監視対象から外すなどの対策を考えます。

GitHubにするにあたって必要なこと

• メンバー全員のGitHubアカウントを作成
• メンバーの作業PCとGitHubをSSH接続できるようにする
• リポジトリを設置するアカウントを決める
  • コラボレーターにメンバーを設定するのか
  • オーガナイゼーションを作成するのか

当初オーガナイゼーションを作成するつもりでしたが、軽く調べたところプライベートにするには課金が必要そうだったため断念。また私がリポジトリを作成しても良かったのですが、あくまでアルバイトですし、新卒就職時には辞めることが決定しているため、期間的な意味でも、社員のメンバーに作成してもらいました。
プライベートリポジトリにする場合コラボレーターは3人までとのことですが、今回の案件は3人以上になることは無いと思われるためこちらは問題になりませんでした。

Gitのフローについて

今回は

• masterブランチ(リリース/客先レビュー用)
• developブランチ(デフォルト)
• featureブランチ(開発時用)

とするGitHubフローとしました。
タスク管理をどうするかの話が決まっていないため、現時点ではIssueを利用することにし、featureブランチの番号はIssue番号に対応させることにします。

なお今回は、開発メンバーがmasterブランチのみでコミットを積んでいくことはしたことがあるとのことだったため、基本的なGitの操作についての説明はある程度省略します。

開発者は、

1. 最新のdevelopブランチをpull
2. 実装するタスクのIssueを確認し、 feature/<Issue番号>ブランチにチェックアウト
3. コーディング
4. git add + git commit + git push origin feature/<Issue番号>
5. Pull Requestを作成
6. PRをmerge
7. developブランチに戻り、1.に戻る

というフローを繰り返します。今回はコードレビューなどは省略になるかと思います。
また、GitHub Actionsなどは設定しません。

ローカル環境の準備

これまでは開発用のサーバーを用意し、そこに全てのソースを保存していましたが、それだと誰かがブランチを切り替えることができないため、必然的に各自で競合しない開発環境(＝ローカルに設置する)を用意する必要が出てきました。
集権サーバーであったときは同じ開発用のDBサーバーに接続すればよかったため、誰か一人がテーブルに対する変更を管理していればよかったのですが、各自がDBを用意するところもカバーする必要があります。
また、DBに対する変更があった場合は作業者がSQLをメモした上で、リリースの際手動で入力する必要がありました。これは作業ミスを誘発すると考え、テーブルやDBに対して変更を生じるSQLも、Gitリポジトリに含めることにしました。

以上のことから、

• 誰が見ても同じ環境を準備できること
• なるべくコマンド量を少なく、わからなくても打てば動く状態にすること
• 必要な情報は１箇所にまとまっていること = README.mdを整備する

を優先しました。
実際のREADME.mdの冒頭は以下です。

---

ローカルの開発環境を用意する

1. git clone
2. create databese <project_name>
3. DB接続情報を/common/database/db_config.php 36行目以降に記載
4. /common/database/migrate/ 配下SQLファイルを実行(yyyymmdd + 01 ~ 99の連番 + テーブルに対する変更内容 ファイルの順に実行)
5. cd public && php -S localhost:8000 実行
6. http://localhost:8000

create database って書いてますが、sql文ではなくて手動で作ってねって意味です。
また、プロジェクトルートにはコンフィグファイル群を設置した/commonディレクトリと、サーバーのドキュメントルートにあたる/publicを設置しており、ローカルサーバー起動時にpublicに移動してphp -Sコマンドで立ち上げる想定です。
こうすることで、現状の開発サーバーと同じパスにすることができました。

---

migrateionっぽく連番を振ることでテーブル間の整合性を取ろうとしています。
今の所上から順にSQLファイルを実行するだけで、テーブル重複に対しても各SQLファイル実行前に

DROP TABLE IF EXISTS `users`;

といったことしかしていませんので、今後よしなにするシェルスクリプトなどを作れればなと思っています。

今後について

上記で触れたマイグレーションを管理するものであったり、Gitフローを周知する上でわかりやすいドキュメントを整備などしていく予定です。