ドリコムの開発を支えるGitリポジトリ

はじめに

これは ドリコム Advent Calendar 2014 の5日目です。

4日目は、@ka_nipan さんによる ドリコムを支えるデータ分析基盤 です。

f:id:GUSSAN:20141205120247j:plain

自己紹介

@gussan

ドリコム歴は10年になります。 アーキテクチャ設計、ミドルウェア・ライブラリ及び社内ツールの開発運用等を担当しています。

本日の話

2年前の12月、メインのソースコードリポジトリをSubversionからGitLabへ移行しました。

本日はGitLabへの移行と運用の話をします。

GitLabに決めた理由

選択肢としてはGitLab, GH:E, Stash等がありました。

メインの機能はどれも十分な機能を有していましたが、 GitLabを選んだ主な理由としては以下の3つです。

  • 継続的にメンテナンス・リリースがなされている
  • 社内にある技術で運用可能である(Rails, MySQL, Redis)
    • もし開発がストップしても社内エンジニアが継続してメンテナンス可能
  • 機能拡張が容易である

現在の規模

f:id:GUSSAN:20141205113235p:plain

  • 総容量: 130GB
  • Push数: 700〜900/day

現在95%程度のリポジトリがgitへの移行を完了しています。

独自拡張

独自拡張についていくつか紹介します。

Git-Subversion同期

Subversionからの移行にあたり、 利用者側の違いを考慮する必要がありました。

  • エンジニア
  • デザイナなど非エンジニア
  • デプロイツール
  • その他開発支援ツール

全てを一度に移行した場合、非常に痛みを伴いますし、 非常に短いサイクルでのリリースを続けるサービスの手は止めたくありません。

そこでGit-Subversion同期機能を組み込み、 Git or Subversionどちらへコミットしても良い状態を作ることで、 まずエンジニアにGit環境での開発に慣れてもらい、 それから非エンジニアやデプロイツールの移行をすすめる形にしました。

エンジニアの皆さんの多大な協力もあり、 subversion上に存在していたリポジトリはほぼ全て移行が完了しています。

ミラーリング

Gitリポジトリが停止した場合、特にリリース作業が遅延してしまうのを避けたいところで、 常にミラーされたGitLab環境を用意しています。

緊急時には数分で切替が可能となっており、安心して運用できます。

(現在まで一度もハードウェア障害は発生していませんが・・)

Ignore whitespaces

これはGitHubにも存在する機能ですが、パラメータw=1をつけることで、 差分表示がgit diff -w(whitespaceの変更を無視)相当になる機能です。

  • デフォルト

f:id:GUSSAN:20141205113003p:plain

  • ignore whitespaces ON

f:id:GUSSAN:20141205113017p:plain

MergeRequestのdiffを確認する場合などに重宝しています。

アップグレードについて

GitLabは毎月22日にリリースが行われており、 弊社ではリリース2週間後を目処にアップグレード作業を行っています。

アップグレード時に注意しておきたいこととして

  • Issueが上がっていないかどうか
  • データのマイグレーションが入る場合は既存データが破壊されないか
  • 独自拡張部分への影響

があります。

package版のGitLabを利用している環境であっても、 カジュアルなアップグレードは避け、上記のチェックを行うことをオススメします。

弊社GitLabのアップグレード手順としては、

  1. 全差分をチェック
  2. 社内版gitlabhqリポジトリへマージ
  3. ステージング環境へデプロイ&修正
  4. 本番環境へのデプロイ

という形で行っています。

変更の影響範囲を本番適用前に全てチェックしておくことで、 本番環境にトラブルが発生した場合でも迅速に解決できています。

バックアップ

標準のバックアップ手段では、深夜からバックアップを開始しても翌始業時刻を突き抜けてしまう問題が有りました。

そこで、バックアップタスクに対して以下の修正を行っています。

  • DB: xtrabackupに頼る
  • リポジトリ: 更新があるRepositoryのみgit bundle

改修した現状でもバックアップ&転送に8時間程度要しているため、 新たな対策が必要な時期となってきています。(スケールアップで乗り切りたい)

リポジトリの容量

容量が7GB(!)を超えるようなリポジトリもあり、 ほとんどの原因は大量の歴史あるバイナリファイルになります。 gitリポジトリが太ることで、サーバ自身の負担も増えますし、 なにより開発作業の足枷にも成り得えます。

こちらに関してはバイナリファイルを別リポジトリに分離し、 filter-branchで該当データを削除するなどの対応を進めています。

また、スマートフォン向けアプリのアセットデータも増大していく傾向にあり、 アセットデータに関しては別の管理方法を模索しているところです。

まとめ

  • SubversionからGitLabへの移行はスムーズにできている
  • GitLab辛いこともあるけど私はげんきです
  • 安定稼働させるためにそれなりに手はかかります
    • GitLabがというよりは、オンプレで運用してるところはどこも大変そう
  • バイナリアッアッ
  • 将来的にはGH:E ver2.0、CodeCommitなども検討

6日目

次は @shinya_131 さんです。