tekitoumemo’s diary

思ったことを書くだけ。長文版Twitter

トップ > githubを導入して一年たったので振り返る

githubを導入して一年たったので振り返る


一年前に全サービスをgitに移行しました。

そろそろ運用も落ち着き、通常通り開発が出来るようになったので振り返ってみようと思います。

はじめに、以前はSubversionを使ってましたが、なぜgithubに移行した方が良いと思ったのか以下に書きます。

リリース時のバグが多い

リリースの曜日は決まっているのですが、リリース日にコミットする人がいたり、いつ誰がコミットしたか管理出来ていなかったのでリリースに「なんだこれは！」ってのが多かった気がします。プルリクエストを導入して、ヤバいソースコードがマージされることは少なくなりました。

ブランチの管理が出来ていない

Subversionのときは一回マージ漏れしたら差分が出過ぎて手に負えません。同期が取りづらい印象。gitはコミット単位の同期になるので確実に同じ内容のブランチが作れるのでミスが少ないですし安心します。

コミットの粒度がめちゃくちゃ

誰も確認しない状態だったので、大量の修正も簡単にコミットされてました。プルリクを導入したことによって人に見られるという意識が増えたのでしょうか？なにもせずにコミットの粒度が整ってきたように感じます。僕のブログも以下の記事のときの月間PV数が50も満たない感じだったけど1500程度の今とは比べ物にならないぐらい文章が丁寧になりました（これでもね。）
tekitoumemo.hatenablog.com
ほんとに何言ってるのかわからん。。

社内の技術力の不安

うちの会社はエリート揃いなので技術力はないことはないのですが、ちょっと新しい技術に興味ある人は少ないかなーと思いました、仕事が忙しいからそれどころじゃないってのもあるんですが。新しい仕組みの理解や運用フローの再認知を含め、今のチームには必ず必要だと感じていました。

協力会社のソース共有が出来ない

厳密にはできるのですが、圧倒的にラクになりました。アカウント作って招待すれば一瞬で使えるようになるし、協力会社さんは社員と比べてどうしてもコミュニケーションが少なくなってしまうのでプルリクはかなり役に立っています。

これらの課題を解決するには、導入だけでは改善出来ないので運用フローも一緒に考えました。ここでは代表的なフローであるGitFlowとGithubFlowを説明します。

GithubFlowとは？

f:id:tekitoumemo:20180226224504j:plain
WEBサービスでは一般的なフローかなと思います。masterブランチからfeatureブランチを作って都度マージしていくやり方です。こちらのフローは常にmasterブランチが改善され、リリースのサイクルが短くなるのでアジャイル開発に向いているフローです。運用方法などシンプルでわかりやすくリリースサイクルが短いという利点はありますが、自動テスト、自動デプロイの環境が整ってなかったり、WEBサービスを作っている人はエンジニアだけではないので、マーケティング、サポートなど様々な職種の人と作り上げていく上では難しさを感じます。スタートアップであれば非常に良いフローだと思います。

GitFlowとは？

f:id:tekitoumemo:20180226230503p:plain
定期的に更新するブランチはdevelop、長期に渡る開発はfeature、緊急で対応が必要な場合はhotfix、リリースはrelease、本番と同様の状態のmasterの5つで構成されている運用方法です。一つ一つのブランチに意味があり、フローを理解するにはちょっと難しいフローかなぁと思います。良い面は役割がきっちりしているので、手戻りが少なく、堅実に運用していることです。人数が多かったり、WEBサービスを取り巻く業種の人がかかわっていたりする際には非常に良いフローとなっています。定期的なリリースを止めずに大きな開発を平行していけるのでサービスを大きく変化させていくことが出来ます。うちの会社は以前も同じようなフローを使っていて、下手に運用を変えるとトラブルにつながるため、こちらの方法を採用しました。運用を変えるというのは、個人にとっては大したことなくてもチームとしては大きな変化をもたらすので注意が必要です。ちなみにreleaseは必要性を感じなかったですし、リリースの際にいちいちブランチを切ってもしょうがないと思ったので運用から外しました。実際にうまく運用出来ているので、正解でした。

次にSubVersionで運用していた仕組みをGitに移行出来るか考えました。
独自のライブラリ群、Areasをexternals (外部参照) を多用していたため、Gitでの代替えを考えました。ちなみにAreasとは以下のようなものです、ここでは説明しません。
チュートリアル: 区分による ASP.NET MVC アプリケーションの編成
Gitでは外部参照がなく、困りましたがSubmoduleを採用し独自のライブラリ群、Areasをリポジトリに分ける作業をしました。
qiita.com
分け方は

大きく分けて、この三つで構成します。こちらで問題なかったのですが、Submoduleが癖がありSVNはシンボリックリンクでSubmoduleは外部リポジトリのコミット番号参照だったので運用方法が理解されるまで時間がかかりました。ここは正解か不正解か難しいところですが、コミット毎に参照できるのでサービスごとの仕様でリリースできるのでなかなか良かったと思ってます。

次にプロジェクトファイルとソリューションファイルのパスを変更しました。なかなかしっちゃかめっちゃかになってるので、ちゃんと修正するのが大変でした。絶対パスで指定されているところは相対パスに、変更された場所はすべて修正しました。いい機会なので不要なものも削除し非常にすっきりしました。

最後にクライアントツールの選定です。
SVNで使っていたSVNのクライアントツールがありましたので、そちらのGit版を採用しました。
TortoiseGit – Windows Shell Interface to Git
極力、今まで使い慣れていたツールなどの運用を変えずに移行することを心掛けていたのでこちらはすんなりいきました。Gitはあくまでもソース管理ツールなので、使えれば良いぐらいなのであまり深堀はしていません。

その他、Jenkinsの設定や移行するプロジェクトのスケジュール管理など移行に伴う作業を一通りやりました。ソース管理の移行は単純にコピーなので簡単なのですが、チームに認知したりスムーズに運用する上でのフローを考えたりなどやることは多かったと思いますが、良い経験になりました。移行してみて、hotfixなどほとんど作成したことないですし運用を含めリリースの精度が上がったので振り返ってみて確実に良かったと思いました。新しいツールを導入することは良いですが、運用を含めチームがより良い方向に進むためにちゃんと考えて運用出来ればよいですね。