Skip to content

Instantly share code, notes, and snippets.

@catatsuy

catatsuy/pixiv_dev_flow_sezemi.md

Last active July 24, 2021 09:44
Show Gist options
  • Star 11 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save catatsuy/76cb8a83181739277c3b to your computer and use it in GitHub Desktop.
Save catatsuy/76cb8a83181739277c3b to your computer and use it in GitHub Desktop.
Download ZIP
Raw
pixiv_dev_flow_sezemi.md

pixivの開発フロー

  • 社内用のリポジトリ管理のためにGitLabを使用
    • pixivはPC・Touch版などがありそれぞれソースコードを一部共有しているためpixiv.gitという1つの大きなリポジトリで管理している
      • 社内で一番大きく関わっている人も多いリポジトリ
    • pixiv.gitは1.4GBくらい（昔は2GB超だったが工夫して減らした）なので外部サービスのGitHubに置くと遅すぎて開発ができない
      • GitHubの障害によりデプロイができなくなるのも困る
      • GitHubにはファイルの容量制限など様々な制限もあるのでそういったことで悩みたくない
      • 社内のデータセンター内で管理する必要がある
    • GitHub Enterpriseを使えば社内のサーバー上にGitHubを立てることができる
    • ピクシブではデータセンターの拠点が複数あるなどちょっと特殊な事情もあるのでソースコードを含めて完全に自分たちで制御できるGitLabを採用
      • 一部パッチを当てている
    • GitLabはソースコードが綺麗（Ruby on Rails）なので今回の題材にしても良いのでは？？（開発環境を作るのに手間がかかる）
  • GitHubのpull requestにあたる機能はGitLabではMerge request
    • pixiv.gitではmasterブランチが常にデプロイされている前提なので各自masterブランチから別のブランチに入り各々開発
    • 開発がある程度進んだらMerge requestを作り、その開発に関わっている OR 一番近い人などにレビューを依頼
      • HUBOTとidobata/hubot-idobataを使ったBOTがチャットツールのidobataに通知
      • WIPという形で開発を始める段階でMerge requestを作るパターンも最近増えている
      • 開発中であることが周りに伝わったり、開発初期段階で議論が進むなどのメリットがある
    • GitLab上のコメントでレビューをしながら修正をしすべての修正が終わればmergeしてよい状態になる
      • pixiv.gitは多くの人が関わり、かつ開発スピードが早いのでmasterブランチとの乖離が大きくなる前にmergeをした方が良いとされている
      • mergeは基本的に開発者本人が行う
      • GitHub Flowに近い
      • 複数人が同時に作業を行うとトラブルになるので社内デプロイツールのpployで『デプロイ開始ボタン』を押してからでないと作業してはいけないというルールで運用
  • CI
    • 社内のGitHubプロジェクトはCircleCIで全pull requestのコミットをテストしている
    • pixiv.gitは社内GitLabで管理しているため外部サービスが使えないのでJenkinsを使ってテストしている
      • Jenkinsは社内でCI以外に定期実行する必要のあるバッチなどにも使用している
      • コマンドの実行結果を簡単に可視化できるので問題が起こってもすぐに調査ができる
      • 設定変更がブラウザ上から容易にできる
      • プラグインを使えば機能を追加できる
    • JenkinsプラグインのGitlab Merge Request Builder Pluginを使って全Merge requestのコミットをテストをして結果をGitLab上にコメント
    • Jenkinsプラグインのtototoshi/jenkins-idobata-notifier-pluginを使ってJenkinsの結果を社内で使用しているチャットツールのidobataにも通知
      • テストが落ちたらすぐに気付ける
  • デプロイ
    • ピクシブのリードエンジニアの @edvakf が開発したScala製でオープンソースなデプロイツールのedvakf/pployを使用
    • pploy上でデプロイを開始するとチャットツールのidobata上で誰がどのリポジトリのデプロイを開始したかが通知される
    • デプロイをするとリポジトリ内に含まれるシェルスクリプトが実行され、本番にデプロイしたこともidobataに通知される
    • pixivのデプロイは各自の判断で行えることもあり1日に平均17回程度のデプロイが行われるためデプロイにかかる時間が短くなるように工夫している
    • 現在は10秒以内で終わる
  • エラー通知
    • pixivでエラーが起こればどういうエラーがどこのファイルで起こったのかなどの情報がファイルに書き込まれて保存される
    • ログ転送のためにpixivのアプリケーションサーバーの全台にfluentdが起動していてエラーが書き込まれればエラーログ収集サーバーに送られる
    • 自社開発のError Log Viewerで発生したエラーを見ることができる
  • revert
    • デプロイによってエラーが起こった場合、そのデプロイを取り消す必要がある
    • pployにはrevertの機能はないのでgit revertでデプロイ前にmergeした変更を取り消してからデプロイをして元に戻す
    • 原因を究明し、変更を行ったら改めてデプロイする
  • 金曜デプロイ禁止
    • デプロイは基本的に各自の判断で行えるが金曜日のデプロイは禁止
    • pixivは夜・土日のアクセスが多いためパフォーマンス的に問題のあるデプロイが金曜日の昼に行われると事故になる
    • デプロイにより致命的なトラブルが発生しても気付くのが遅れた場合、金曜日だと次の日が休みのため土日に対処できない
    • どうしてもデプロイしなければならない場合はマネージャーにその旨を共有し許可を得る必要がある
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment