数年前、所属していた会社で、SVNからGitHub Enterpriseに移行した経験をまとめておきます。
GitHub Enterpriseを導入した
経緯
- 開発スタイルに限界を感じていた
- SVN
- ブランチを切るのがしんどい
- マージするのがしんどい
- 運用がしんどい
- redmine
- 設定項目が多いくせにほとんど使ってない
- チケットを作るのがしんどい
- 設定項目が多いくせにほとんど使ってない
- SVN
- PDCAサイクル、リリースサイクルを回すにはしんどい作業が多くて辛かった
- 求めている開発スピードには程遠い
Enterpriseを選択した理由
- Gitにすればブランチ切るの簡単じゃん
- プルリクからのマージ簡単じゃん
- Issueがあればredmine不要じゃん
- 開発しているサービスの特性上、github.comにコードを置くのは少し不安
- オンプレ環境でEnterpriseを動かせば解決
Enterpriseのライセンス料、高いじゃん
- 10人分の1年間のライセンス料金が大体40万円を切るくらい
- GitBucketでもいいじゃん。と社内から声が出たことも
- オンプレ環境で動かした時、何か問題があったら誰が対応する？
- 対応、調査する工数を考えると、年間40万円は安いと考えるべき
- 人月20日を稼動日とすると、1人当たり1日160円程度で利用することができる
- 上司に説明したところ、トライアル前に導入決定のウルトラC
動作環境を用意
- 代理店のマクニカネットワークスさんから導入の手順書を頂いた
- 手順書通りにしたら30分もかからずに動作環境を用意することができた
- トライアル期間中に自社での運用方法を検討
- 実際に動作させながらの方が検討しやすい
- オンプレでもいいしAWSのインスタンスでも可
- 2.9からGCPにも対応
SVNからのコードファイルの移行
- SVNから移行対象のプロジェクトのソースコードをエクスポートして、GitHubの方へpush
- SVNからの移行ツールもあるとのこと
- 全てのリポジトリを一度に移行するのではなく、順序を決めて一個ずつ移行していった
redmineからのIssueへのデータ移行
- redmineのチケットをCSV出力
- GitHubのAPIを利用して、CSVファイルから一括でIssueを作成するスクリプトを作成
- ラベルなどもここで一括でつけることが可能
- 画像の移行ができなかった
GitHubからSlackへの通知
- 会社でのコミュニケーションはSlackがメイン
- GitHubでの通知をSlackでも受け取りたい
- 公式の通知アプリは、Slack上でのメンションに対応していない
- 自分への通知に気づかないことが出てくる
- Slack上でのメンションに対応した通知スクリプトを作成し、GitHubのリポジトリのWebhookに登録
- GitHubのIssue上でのコミュニケーションがより活発になった
導入して良かったこと
- プルリクエストの効果が絶大
- マージ前にレビューを通すことで、コードの健全性が保たれる
- コードベースでのコミュニケーションができるので、伝えたい内容の意図が伝わりやすい
- 潜在的なバグが減った
- Issueがシンプルで、問題、改善点を明確にしやすい
- redmineは項目が多すぎて何をどう見たらいいのかわからないことがあった
- Issueはマークダウン記法でシンプルに書けるので、物事をシンプルに明確に記載することができるようになった
- ブランチを切るのに抵抗がなくなった
- 並行して別機能の開発を進めることが簡単になったので開発スピードが上がった
- テクニカルサポートが手厚い
- 代理店のマクニカネットワークスさんにメールを送ると、遅くても半日以内には返信がある
- GitHub社への連絡とやりとりをやってくれる
- GitHub社とのやりとりは基本英語なのでとても心強い
- GitHub.comがダウンすると Twitterでドヤ顔できる
導入にあたって注意など
- 移行するならそれなりに移行用のアプリケーションやスクリプトを用意しないといけない
- 動作環境構築時に、ルートディレクトリとデータディレクトリは別ディスクにしたほうがいい
- 同一ディスク内に入れてしまうと、動作が劇的に重くなってしまい使い物にならなくなる
- おそらく定期的なバッチ処理などがルートディレクリに実行されているのだと思う
- ブランチ戦略は導入前にどのフローが自社に合っているかきちんと検討しておくことが大切
- 弊社では開発した機能をまとめてリリースするようなスタイルなのでGitHub Flowは合わない
- Git Flowはブランチの種類が多くて運用がめんどくさそう
- 独自のブランチ戦略を導入した
- 現在の開発スタイルを全て維持したままGitHubに移行することは考えないほうがいい
- 何かしらGitHubに合わせた運用に変えたほうが良いこともある
運用してからの色々
- 運用が原因でダウンしたことは一度もない
- 先人たちのおかげ
- 1年以上運用したが、一度もダウンしたことはない
- ずっと安定稼働している
- メジャーバージョンアップ時に障害が発生しやすい
- メジャーバージョンアップがリリースされてから1日は待った方がいい
- 2.8、2.9系へのメジャーアップデート時に不具合があった
- 販売代理店から注意喚起のメールがくる
自分も自社に導入したいと考えてるあなたへ
- 45日程度のトライアルがあるので、さっさとインストールしよう
- 実際に動作している画面を見せて稟議を通そう
- 口で言うより実際に見せた方がいい
- トライアル期間中に自社での運用の方向性を決めよう
- ブランチ戦略
- Issueのラベル、マイルストーンの種類など
- 現状のリポジトリからの移行方法とスケジュールを決めよう
- 全てのリポジトリを一度に移行するのはやめたほうがいい
- 2020年現在であれば、githubのクラウド版でTeam Planの契約でも良さそう