シンクロ・フード エンジニアブログ

飲食店.COMを運営する、株式会社シンクロ・フードの技術ブログです

シンクロ・フードのブランチ運用フロー

シンクロ・フードの五十嵐です。
今回は、私たちの開発フローについてお話したいと思います。
特にGitのブランチ運用については皆さん頭を悩ませる部分だと思いますので、弊社の紆余曲折した経緯も踏まえて公開します。
Gitへの移行を検討している方などの参考になれば嬉しいです。

リリース頻度

お話の前提として、弊社のリリース頻度を紹介します。
平日は、ほぼ毎日リリースをしています。一日数回リリースする日もあります。
月間で捌くチケット数(≒featureブランチ数)の平均は約170です。
それなりの規模になってきたため、開発フローの安定化や効率化は全体の生産性に直結すると考えており、現在も改良し続けています。

GitHub Enterprise の利用

バージョン管理はGitで行っており、GitHub Enterpriseを利用し、プルリクベースで開発を行っています。
全てのプルリクは必ずコードレビューを受けてからマージされます。レビュアーは基本はランダムに決めています。
また、毎日の朝会でレビューの状況を可視化しており、レビューが依頼されたまま放置されることを防いだり、レビューの負担が偏った場合に調整して分散できるようにしています。

Enterpriseにした理由としては、弊社はISMSを取得していて、情報セキュリティマネジメントの観点から、機密性を重視しました。
可用性という面でも、今はEnterpriseのほうが安定しているかもしれません。導入後1年以上が経ちますが、発生した障害はゼロです。

ブランチ運用

本題のブランチ運用についてです。
現在はGitHub Flowを参考にしつつも、独自にアレンジした運用をしています。

f:id:synchro-food:20160318183348p:plain

  • masterブランチは常にデプロイ可能、本番環境と同一の状態
  • developブランチはmaster+テスト中のブランチが取り込まれた状態
  • featureブランチはチケットごとにmasterブランチから作成される
  • featureブランチからdevelopにプルリクエストが作成され、コードレビューを受ける
  • コードレビューがOKならdevelopにマージされる

しかし、この状態に落ち着くまでには、紆余曲折がありました。

Git導入以前

f:id:synchro-food:20160318183611p:plain

多くの企業が同様だと思うのですが、弊社はGit導入以前はSubversion(以下SVN)を利用してバージョン管理を行っていました。
SVN時代は、release - trunk のブランチ構成で、開発者はtrunkにガンガンcommitしていました。
ステージング環境および本番環境にデプロイする際には、releaseにチェリーピックで反映し、releaseブランチをそのままデプロイしていました。

これはこれで数年に及ぶ運用実績のあるフローでしたが、下記のような問題が出てきて、2014年の7月頃から、真剣にGitへの移行を検討することになりました。

  1. 開発者が増えてきて開発環境での競合が増えてきたこと(チケットごとにブランチを分けたい)
  2. コードレビューの工数が増えてきたこと(プルリクを活用してレビューを楽にしたい)
  3. 中途採用の面接時などにバージョン管理ソフトを聞かれるようになったこと(採用戦略としてGit使ってますと言いたい)

Git導入に向けての検討

上記の課題解決のためにGit導入を決意しました。
SVN -> Git へのリポジトリ変換も当時すでに複数の事例や手順の紹介があり、大きな問題にはなりませんでした。
デプロイにはJenkinsを利用していましたが、こちらもGit用のプラグインが存在したため、問題ありません。

弊社が頭を悩ませたのはやはりブランチ運用でした。
まず、弊社の開発フローでは、環境が4つに分かれています。
本番環境、本番デプロイ前の検証を行うステージング環境、企画責任者(非エンジニア)が受け入れテストを行うためのテスト環境、そして各開発者の開発環境です。
SVN時代は本番環境とステージング環境がreleaseブランチ、テスト環境と開発環境がtrunkです。
これを、release -> masterブランチ、trunk -> developブランチにそれぞれ変更すれば、特に大きな変更点なく移行ができると考えていました。
masterブランチからチケットごとにfeatureブランチを作成し、developにマージし、受け入れテストがOKになればmasterにマージするというフローです。

しかし致命的なことに、SVN時代のmasterとtrunkの二大ブランチは根が全く異なっていました。つまり、親子関係がなかったのです。
実際にGit移行のリハーサルでマージを試みると大量の競合が発生してしまい、とても解決しきれない程でした。
これでは、featureブランチをmasterから切った場合にdevelopブランチへ自動マージするのが困難…というよりも無理だということが分かりました。

考えられる手段としては、移行コストと割り切ってmaster(旧release)とdevelop(旧trunk)のマージ作業をしてしまうことですが、弊社は当時8サイトの運営をしており、ライブラリなども含めて移行対象となるリポジトリは10を超えていました。
多数のリポジトリで正しく競合を解決してマージした上に、全機能の動作確認を行うとなると、非常に大きな工数がかかることが予想されます。しかも、その動作確認中にも新しい機能開発はどんどん進んでいきます。

そこで、なんとかmasterとdevelopが断絶したまま運用できないかを考えました(今思えば、この発想が間違いだと思われるのですが…)。
まず当初の想定通りにmasterからfeatureブランチを作成した場合、masterへのマージ(≒本番デプロイ)は簡単に行えますが、developへのマージ(≒受け入れテストの開始)が難しくなります。
また、コードレビューは受け入れテスト前、つまりdevelopブランチへのマージ時に行いたいです。当然のことながら、developに向けたプルリクエストの差分は、そのブランチに関係のある変更だけが出てこないと困ります。
以上のことから、featureブランチはdevelopブランチから作成することが妥当と考えられました。

次なる課題は、developブランチから作成されたfeatureブランチから、どのようにmasterブランチに反映するかというものです。
調査を進めると、Gitにもcherry-pickコマンドが存在することが分かりました。
cherry-pickコマンドを利用すれば、履歴の断絶しているmasterへの反映も行えそうです。実質SVN時代とほぼ差のない開発フローが作れそうです。実際に試してみたところ、上手く運用ができそうでした。

以上の経緯から、移行直後の開発フローは以下のように固まりました。

  1. developブランチからfeatureブランチを作成する
  2. featureブランチからdevelopブランチにプルリクエストを作成する
  3. コードレビュー後にプルリクエストをマージする
  4. 受け入れテスト後にmasterにfeatureブランチのコミットをcherry-pickする
  5. ステージング環境でテストする
  6. 本番環境にデプロイする

折衷案のようなブランチ運用ですが、Git移行の目的であった以下3点は満たすことができていました。

  1. チケットごとにブランチを分けたい
  2. プルリクを活用してレビューを楽にしたい
  3. 採用戦略としてGit使ってますと言いたい

cherry-pick運用の廃止

運用が2~3ヵ月過ぎたころ、次第に無視できないトラブルが発生するようになってきました。
それは、masterへのcherry-pick時の競合解決の失敗や、cherry-pickすべきコミットが多い場合に漏れが出てしまう、更にはdevelopには存在するがmasterには存在しないクラスへの依存に気付けない等のトラブルです。
上記のようなトラブルは、当然ながらエラーが発生したり、バグの温床になったりと、サイトに致命的なダメージを与えてしまいます。

こうしたトラブルには都度、解決策を考えて実施してきました。
例えば1番目の問題については競合解決用のブランチをmasterから作成してレビューを行うようにしたり、2番目の問題についてはdevelopへのマージコミットをcherry-pickすることで漏れを無くす、等の対応を行いました。

しかしながら上記対応は対症療法でしかなく、やはり根本的な問題になっているのは、featureブランチからmasterブランチに直接マージできないことです。
本来なら緊急時に使うべきであろうcherry-pickコマンドを日々の運用で利用してしまっているという状態の気持ち悪さもあり、masterブランチとdevelopブランチの履歴を統一する必要があるという判断に至りました。

そこで弊社は、現在のdevelopブランチを破棄し、新しくmasterブランチからnew-developブランチを作成することで履歴を統一することにしました。
Git移行時にこの判断を見送った経緯としては、masterとdevelopのマージ作業は現実的ではないことが理由でしたが、それはこの時も変わりませんでした。
しかしGit移行後の現在、開発中の内容は全て各featureブランチに存在しています。
移行前はmasterには存在しないがdevelopにのみ存在する開発中の内容を救う手段がマージ作業以外に思い浮かびませんでしたが、各featureブランチが存在する現在は、その内容を拾うのは、それこそcherry-pickコマンドで容易になっています。

そこで、新しくmasterブランチから作成されたnew-developブランチに、開発中のfeatureブランチの内容をcherry-pickで反映していくという作業を行って、新しいブランチ運用を開始しました。旧developブランチは直後に削除され、new-developブランチがdevelopブランチへとリネームされています。
その後、masterブランチへのfeatureブランチのマージもプルリクエスト上で行うことにより、マージ漏れや競合の解消ミスなどもレビューで気付けるようになりました。

現在の開発フロー

上記のような紆余曲折を経て、現在の開発フローに落ち着きました。

  1. 開発ブランチで各開発者がローカルで開発を行う
  2. ローカルでの開発が完了したらdevelopブランチへのプルリクエストを出し、レビュアーがレビューを行う
  3. レビューが完了したらdevelopブランチにマージされ、受け入れテストが行われる
  4. テストが完了したら開発ブランチがmasterブランチにマージされ、ステージング環境でテストが行われる
  5. 問題なければmasterブランチを本番環境へデプロイする
  6. masterブランチからdevelopブランチにマージが行われる(Jenkinsで自動化)

GitHub Flowとの差異としては、masterに取り込む前にdevelopブランチを挟んでいます。
すでに軽く触れていますが、企画責任者(非エンジニア)が受け入れテストを行うための環境です。
非エンジニアなので手元に開発ブランチを落としてきて動作確認するということができないため、テスト用の環境を用意しています。
また、開発ブランチ同士の競合などがdevelopブランチで検知できるという利点もあります。
そのほか、今回は詳しく触れませんが、developブランチが反映されるテスト環境では、Seleniumを用いたE2Eテストが定期実行されており、サイトの品質を担保してくれています。

また、最後のmasterブランチからdevelopブランチへのマージは、現在も正解なのかどうか自信がない部分です…。
取り入れた理由としては、developブランチへのプルリクエストで余計な差分が発生するのを防ぐためです。
masterブランチからdevelopブランチへのマージを行わないと、masterブランチには存在する本番反映のためにマージコミットが、developブランチには存在しないという理由で、関係ないファイルが差分に挙がってきてしまうという現象が発生していました。
Git Flowでもreleaseブランチからdevelopブランチにマージする手順があるので、大きくは間違っていないと思うのですが、どうでしょうか。

なお、releaseブランチを作成しない理由としては、弊社のリリース頻度が多いため、リリース作業の負荷を大きくしたくないためです。
この辺りは各種ツールやデプロイ方法の工夫で乗り切れる部分かもしれません。

最後に

以上、弊社のGitブランチ運用の経緯と現在の開発フローをご紹介しました。
色々なトラブルは発生しましたし紆余曲折もありましたが、現在はGit/GitHubの恩恵を受けながら、かなり快適に開発やコードレビューが行えるようになっています。

尚、シンクロ・フードではエンジニアを大募集しています!
こうした開発フロー改善以外にも色々なことをやっていますので、少しでもご興味があれば、気軽にお話しする場を設けますので、以下よりご連絡ください!

キャリア採用 | シンクロ・フード採用サイト

Webサイトの文字コードをShift_JISからUTF-8に変更するときに実施したこと

こんにちは、シンクロ・フードの大久保です。
10年以上運用しているWebサービスだと、文字コードがShift_JIS、という状況は多いのではないでしょうか。
弊社もそうだったのですが、昨年、自社で運用するWebサイトすべての文字コードをShift_JISからUTF-8に変更しました。
今回はこの対応について実施したことをご紹介したいと思います。

前提条件

WebサーバはApache、WebアプリケーションサーバはTomcat、DBサーバはMySQL5.6を利用しています。
Webサイトは全部で6サイト、すべてJavaで書かれたWebアプリケーションで、その中のメインである飲食店.COMのJavaファイル数は約2000ファイル、cssやjs、htmlファイルなどを含めると約10000ファイルくらいです。Webアプリケーションですとそこそこ大きい部類だと思います。

なぜUTF-8にするのか

Shift_JISのままで良いのでは?という意見があるのかもしれませんので、念のため弊社がUTF-8化した代表的な理由を挙げておきます。

  1. 入力できる文字の増加(㈱、㈲、①など)
  2. UTF-8で書かれたJavaScriptとの連動がスムーズになる
  3. nodejs系フロントエンドツールがShift_JISに対応していないことがある

1は昔からある問題なので、今回変更した理由の動機としては薄いです。
2はJavaScriptのMV◯◯系フレームワーク(AngularJSやKnockoutJS等)を使う度に悩まされている問題で、JavaScriptを使ったリッチな動きのサービスを作る機会が増えたため、避けて通れない問題となっていました。
3は、GruntやGulpで実行するようなプラグインが、Shift_JISだと動かないことがあるという問題で、そもそもそんな制約に縛られるのが嫌だ、と開発者のストレスが溜まっていました。

一言で言うと、モダンなフロントエンド開発を進めていくたびに、「UTF-8だったら楽だなあ…」と思うことが増えてきたため、対応に踏み切ったというわけです。

実施したこと

文字コードを変更するにあたって実施したことを以下に挙げます。
実際にはこれ以外にも細かい対応がありましたが、大きくは以下の対応です。

プログラムファイルそのものの文字コードを変更する

ファイルの文字コード変更です。エディタ等で一気に変えることができるので、簡単です。
弊社では、Linuxのnkfコマンドを使って一気に変換をしました。

プログラムファイル中に記載されている文字コードを変更する

ファイル内に登場する、Shift_JISやsjisなどといった文字コード指定を、UTF-8に修正します。
こちらもエディタ等で一気に置換をすることができます。
弊社では、Linuxのsedコマンドを使って一気に置換しました。

メールの文字コードをiso-2022-jpからutf8に変更する

サイトをUTF-8にするので、こちらも一緒に対応しました。
弊社のサービスは年配の方やWebに疎い方が使うことが多いため、古いメールクライアントを使っている可能性があり、少し不安なポイントでした。結果的には、文字化けする、という問い合わせは数件のみでした。

DBデータの文字コードを変更する

alter文を使って、DBのデータを変換します。
弊社ではMySQLを使っているため、alter文はinformation_schemaから一気に自動生成するスクリプトを書いて生成しました。
実際に流してみると、変換に2時間くらい必要で、ここはメンテナンスとしてサイトを停止することで対応しました。
データ量が大きいサービスを運営している方は、ここが一番のネックになるかもしれません。

各種サーバ設定の文字コードを変更する

ここは普通に変更するだけです。特に問題はありませんでした。

特別な対応をしたこと

上記の対応とは別に、特別な対応をしたことが2点あります。

  • 検索エンジンにインデックスされている、Shift_JISでURLエンコードされたパラメータをどうするか
  • 開発中コードとの衝突問題

1つずつ説明いたします。

検索エンジンにインデックスされている、Shift_JISでURLエンコードされたパラメータをどうするか

フリーワード検索の結果などで、日本語の文字列を含むパラメータが、検索エンジンにインデックスされていることがあると思うのですが、その文字列はShift_JISでURLエンコードされています。Shift_JISでサイトを運営していれば当然だと思います。
その状態で、WebサイトをUTF-8に変更すると、検索エンジンからはShift_JISでURLエンコードされたパラメータが飛んでくるにも関わらず、UTF-8でURLデコードすることになってしまい、文字化けが発生してしまいます。
リンク元である検索エンジンにインデックスされているURLを変更できれば良いのですが、それはできません。

対応策

まず思いつく対応策は、URLエンコードされた文字列から、文字コードを逆引きする、という方法です。
これができれば、文字コードに応じてURLデコードするだけなので簡単です。
ですが、URLエンコードされた文字列から文字コードを判定するは困難である、と結論付け、この方向はやめました。
今思うと、この方向性を進めることもアリだったのでは?と思っています…。
[参考] http://clikington-saito.com/UrlEncode/UrlEncode.html

そこで僕たちが取った手法は、判定ができないのであれば、パラメータ名を分ければいい!という、かなり強引な手法です。
まず日本語がやりとりされるであろうパラメータを抽出し、パラメータ名を別名に変えます。具体的にはパラメータ名に_uを付与しました。
そして、旧名(_uが付かないパラメータ)の場合はShift_JISでURLデコードし、_uを付けて301リダイレクトを実施。
新名(_uが付いているパラメータ)の場合はUTF-8でURLデコードしました。

これで問題は解決するのですが、この別名変換処理は、UTF-8への変更を反映すると同時に有効にしなければならないため、事前にコード内に処理を埋め込みつつ、設定値によって無効化しておき、UTF-8への変更と同時に有効化する、という方法も行なっています。

文字コード変更全体の中で、工数を一番かけたのがココです。文字化けを受容する選択肢もあったのですが、やはり検索エンジンからのアクセスは少しでも無駄にしたくなかったため、丁寧に実施しました。概ね成功したと思います(一部文字化けは発生してしまいましたが…)。

開発中コードとの衝突問題

弊社は、バージョン管理にgitを使っており、常時10名以上のエンジニアがブランチを切って開発を繰り返しています。
もし、文字コードを変えるのであれば、以下のような手順になります。

  1. gitのmasterブランチから作業用ブランチを切り
  2. 文字コード変更処理を加え
  3. テストを実施
  4. masterへの取り込み

この手順の中で、時間がかかるのは3番目のテストです。テストをしている間に、他の開発者がmasterからブランチを切って開発を実施し、先にmasterに取り込まれてしまうと、文字コード変更のための修正がmasterに取り込まれる時点で確実に競合が発生してしまいます。

対応策

これを解決する方法としては、リリース直前まで、gitのブランチを切らない、ということで対応することにしました。

まず、gitのmasterからブランチを切ることと、文字コード変更処理をすること、この2つを一気に実施するシェルスクリプトを書きます。
テストをする際は、毎回このスクリプトを使うことで、現時点の最新状態をUTF-8にしてからテストを行い、毎回破棄していました。
そしてデプロイ前日のみ、開発者にはブランチを切ることを一時停止してもらい、上記スクリプトを実行、masterへマージ、本番デプロイ、という作業を行ないました。

尚、この状態だと、開発者の手元にShift_JISで開発中のブランチが残ってしまうのですが、こちらについては、手元のブランチをUTF-8化するスクリプトを用意し、こちらを個別に実行してもらうことにしました。

インターンを含めると10名以上が同時に開発しているリポジトリですが、この方法を用いることで、最小限の工数でプログラムの文字コードを変更することができました。

文字コード変更後の感想、反省など

その他、実際にやってみて起こった出来事などを書いておきます。

MySQLの文字コードは、utf8mb4を使うべきだった

はじめはMySQLの文字コードはutf8にしていたのですが、サービスを運用している中で、登録できない文字がある…ということに気づきました(𠮟、など)。
これは4バイトの文字で、こういった文字を格納するには、utf8mb4という文字コードにしなければならない、ということを後で知りました。
ですので、この変換のためにもう一度深夜にメンテナンスを実施しています…。

MySQLの設定値、group_concat_max_lenを伸ばす必要があった

Shift_JIS->utf8mb4ということで、MySQL内で格納されるバイト数が2バイトから最大4バイトまで増えています。
この変更で見落としていたのが、group_concat_max_lenという設定値…。
場所は少ないのですが、group_concat関数を使っている部分があり、この結合結果文字数が、デフォルトは1024バイトまでしか保持できず、文字コード変更後はこれを超えてしまい、エラーになってしまいました(厳密にいうと、group_concatの結果が切断されます)。
こちらは、group_concat_max_lenを1024から2048に変更することで対応しました。

[mysqld]
group_concat_max_len=1024 // これを2048に変更する

最後に

以上、かなり大雑把な説明ですが、弊社が行なったWebサイトをUTF-8にする際に実施したことをご紹介しました。
工数はかかりましたが、移行後は文字コード関連のトラブルはほぼ発生しなくなり、かなり快適に開発することができています。
対応自体は一部かなりの力技になってしまいスマートとは言えませんが、Shift_JISのWebサイトをUTF-8化する際の参考になれば幸いです。

尚、シンクロ・フードではエンジニアを大募集しています!
こういったレガシー環境をモダン化する対応以外にも色々なことをやっていますので、少しでもご興味があれば、気軽にお話しする場を設けますので、以下よりご連絡ください!

キャリア採用 | シンクロ・フード採用サイト

シンクロ・フードのサービスとシステム構成

シンクロ・フードの大久保です。当社でもエンジニアブログを始めてみました。
まずは弊社サービスのご紹介と、システム構成を簡単にお伝えしたいと思っています。

サービスと組織

シンクロ・フードは、「飲食店.COM」や「求人@飲食店.COM」など、飲食店向けのWebサイトを6つ運営しており、ユーザーは主に飲食店をこれから開業しようと思っている方や、飲食店を運営している方となります。

http://www.inshokuten.com/
http://job.inshokuten.com/

主サービスとなる「飲食店.COM」は2003年9月にリリースしたサイトなので、サービス提供から13年経っており、かなり古いサイトです。
飲食店を運営する方にはそれなりに認知されているサービスですが、一般の人はほとんど知らない、ちょっとマイナーなB2Bサイト、という感じですね。
サイトの規模でいうと、小~中規模にカテゴライズされるかと思います。このWebサービスを、9名のエンジニア+インターン6名で開発しています。

言語とフレームワーク

プログラミング言語は、Javaがメインで、WebサービスはすべてJavaで開発しています。バージョンはJava8ですが、昨年末にバージョンを上げたばかりですので、Java8らしいコードはまだ少ないです。

Webアプリケーションフレームワークは、Seasar2というフレームワークを使っています。Seasar2はかなり古いフレームワークですので、移行について検討を進めており、現在、新サービスはRubyOnRailsで開発、旧サービスはSpringBootに載せ替え、という方向で検討・開発を進めています。

ただ、Seasar2はとても素晴らしいフレームワークで、使い方を色々と工夫することで、かなりの生産性を出すことができました。個人的にも愛着のあるソフトウェアで、Seasarコミュニティの方々には非常に感謝しております。

インフラ

サーバはAWSで運用しています。こちらは2015年3月に移行しました。
Webサーバは、Apache2.2+Tomcat7で運用しています。DBサーバはMySQL5.6です。
Apache、Tomcat、MySQLという組み合わせは13年前から同じで、ずっとこの構成で運用しています。

ApacheはNginx、TomcatはJettyなど、新しいサーバへの切り替えも都度検討に挙がるのですが、自社内での運用実績が無いことが理由で、切り替えに至っていません。
(Nginxはリバースプロキシで使っていることもあり、徐々に運用実績が溜まってきましたが…) MySQLはRDSではなく、EC2インスタンスにMySQLサーバをインストールして使っています。

今のところサーバの台数は10~15台くらいの中で収まっており、冗長構成を維持しつつ、できるだけ台数を増やさないように工夫しています。

最後に

以上、かなりざっくりですが、シンクロ・フードのシステム構成です。
大きなトラフィックを捌いているわけではありませんが、弊社のような小~中規模のWebサービスを運営している方は沢山いらっしゃると思いますので、その参考になれば良いと思い、ご紹介してみました。

直近2年は、長期間運用しているサービスにありがちな技術的負債の返却や、レガシー環境のモダン化などを進めていましたので、その課程なども、このブログでご紹介していきたいと思います。

最後に、シンクロ・フードではエンジニアを募集しています。少しでも興味があれば、気軽にお話しする場を設けますので、以下よりご応募ください。

キャリア採用 | シンクロ・フード採用サイト