Git導入による課題解決と成果
はじめに
テーマ「今年の最も大きなチャレンジ」として投稿しています。
成果として、ジュニアメンバによる誤コミットを仕組みで解決し、開発の手戻りがなくなりました。
チャレンジの概要
セクション1~4
Gitの導入を通じて、ジュニアメンバーの誤コミットを防止し、開発の手戻りを削減する仕組みを構築しました。
具体的には、バージョン管理ツールをSubversion(SVN)からGitへ移行し、GitLabをオンプレで構築することで、チーム全体の開発プロセスの効率化を実現しました。
後半部
GitLab構築に際して直面した課題と、その解決方法を紹介します。
課題にはパッケージの取得、プロキシの設定、ポート競合の回避などが含まれ、それぞれに対する具体的な対処方法や参考URLも記載しています。
1. 本題
1.1. 背景と導入の目的
SVNによるバージョン管理を行なっており、ジュニアメンバによる誤コミットによるデグレコミットが頻発し、開発効率が低下していました。
Gitの導入により以下の効果を期待しました。
- 品質向上：コードレビューを開発プロセスに組み込み、デグレードを防止。
- コスト削減：誤コミットの修正に要する時間を削減。
以前から対策としてGitを利用するように提案は行なっていたがきっかけがなかった。
提案資料：speakerdeck
1.2. Git導入に至った経緯
小規模案件でのサブリーダーを任された際、裁量を活かしGitを導入しました。
Gitは以下の点で優れていると考えました。
- 軽量なブランチ管理：タスク単位のブランチ運用が容易
- 標準的なツール：GitHubやGitLabなど、サードパーティツールとの親和性が高い
- コードレビューの促進：プルリクエスト (PR) やマージリクエスト (MR) により開発サイクルを改善
1.3. バージョン管理の問題点や制約
Git導入に際し、以下の問題点や制約がありました。
学習コスト
SVNからGitへの移行に伴い、チームメンバーの学習負担が発生。
外部ツール利用の制限
セキュリティの観点から、GitHubなどの外部リポジトリサービスの利用が禁止されており、オンプレミス環境での対応が必須。
2. Gitの導入計画
2.1. 導入の目的とゴール設定
Git導入の目的は、誤コミットの防止と開発効率の向上です。このため、GitLabをオンプレミスに構築することを決定しました。選定理由は以下の通りです。
豊富な情報量
GitLabに関する技術情報が多く、トラブル発生時の対応が容易。
機能の充実
マージリクエスト (MR) を活用することで、コードレビューを導入しやすい
2.2. チーム全体の準備と教育
Gitの導入にあたり、メンバーがスムーズに移行できるよう、以下の取り組みを行いました。
手順書の作成
- 各PCからのSSH接続手順書作成
- Git操作手順書の作成
- 管理者向けの手順書作成
勉強会の実施
- メンバーへの勉強会の実施、学習教材提供
勉強会ではMixi社の研修資料を活用させていただきました。
2.３. Gitフローやブランチ戦略の選定とその理由
運用モデルには「GitHub Flow」を採用しました。
理由：
「GitLab Flow」や「Git Flow」と比較してルールがシンプル。
初期段階では動作するソフトウェアが存在しなかったため、最終的な成果物をゴールとするGitHub Flowが適していました。
基本は以下の構成:
- main:
- 短期的なfeatureブランチ
PRベースの運用をし、コードレビューを行い、featureブランチはmainへマージされる運用法法。
4. 成功と課題の振り返り
4.1. 導入によって得られた成果
【個人として】
完全独力でオンプレ環境へGitLabを構築し、チームへのGit普及を行なった。
日常の学習結果を業務へ活用し、提案/改善を遂行できた。
【組織として】
PR（GitLabではMR:マージリクエスト）ベースでの開発を適用することで誤コミットの受け入れが０となった。
ブランチ運用モデル（GitFlow）を意識したブランチ管理で並行/先行した機能開発が行えた。
チーム外から構築したGitLabを使ってみたいなどの声があがるようになった。
4.2. 予期しなかった課題と対応策
ブランチの概念
問題: ブランチ運用に慣れていないメンバーが戸惑う。
対応: 初期段階ではタスクごとのブランチを代表者が一括作成。メンバーはコミットとプッシュに集中する運用に変更。結果として、メンバーの操作負担が軽減。
現在では操作にも慣れているようで、ブランチ作成からMRを作成まで一連の流れで作業をいただけるようになりました。
4.3. 予今後の発展の可能性
こうした取り組みをさらに進化させ、CI/CDの導入など開発速度の向上とチーム全体のスキルアップを実現する
後半：GitLab立ち上げまでの超えてきたハードル
OSの設定
OSはCentOSのイメージが社内にあったため、ダウンロードの手間を惜しみそれを利用。
yumのアップデートを実行する際にミラーサイトがないと怒られる場合がある
その場合ミラーサイトを変える（ちゃんとあるやつを探し出す）
yum / curl プロキシを設定する。
社内なのでプロキシの設定が必要でしたので設定しました。
後述のcurlの設定も必要。
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh -x {PROXY_URL} | sudo bash yum install gitlab-ce
上記にしても取得したシェルの中でもcurlしているため、curlの設定にもプロキシ入れたほうが良い
vi ~/.curlrc proxy={PROXY_URL}
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash yum install gitlab-ce
GitLab HTTP待ち受けポートの変更
HTTPの標準ポート(80/tcp)はほかサービスで競合するのが嫌だったので8888にしてみる
vi /etc/gitlab/gitlab.rb external_url 'http://{SERVER_URL}:8888'
ポート開放
待受ポートを変えたのであればそのポートを開けないと見れるものも見れないので開ける。
firewall-cmd --zone=public --add-port=8888/tcp --permanent sudo firewall-cmd --zone=public --remove-port=8888/tcp --permanent firewall-cmd --reload
ルートで操作し続けたのかGitLabが502エラー
GitLabのコマンド
起動、停止、再起動
gitlab-ctl start
gitlab-ctl stop
gitlab-ctl restart
設定の再構築
gitlab-ctl reconfigure
Discussion