nanapi Ver5をリリースするときに使った社内リリースの仕組み

久々のエントリーです。先日、3周年ということでnanapiをリニューアルしました！今回は「メディアからプラットフォームへ」をコンセプトとし、大幅なリニューアルを実施しています。
リニューアルのコンセプトとかは、詳しくはこちらに書いてあります。
nanapiがVer5.0にバージョンアップしました : けんすう日記

社内リリースの重要さ

UIやデザイン、細かい機能など制作側としてはすごく作り込んでいるわけですが、数週間1つのプロジェクトにコミットしているとなかなか客観的に見ることができなくなってきます。
そんな時は客観的な意見をもいたくなるものですが、その意見のもらい方がなかなか難しい。
弊社もサービスを立ち上げてから3年が経過しているわけで、従業員数もそれなりの人数になってきています。となると、開発環境やステージング環境を見てもらうにしても、面倒な手順がちょっとでもあるとなかなか難しかったりするものです。
それでも事前にサービスを見てもらうことで細かいバグを潰すことができたり、意見も取り入れることができるのですごく重要なステップです。

この問題を解決するために、今回のリリースではちょっとした仕組みをいれてみました。

サーバ構成

nanapiでは上段にLoadbalancerをおいて、webサーバへバランシングしているというごく一般的な負荷分散の手法をとっています。
Loadbalancerには、apacheのmod_proxy_balancerを利用しています。
この際のapacheの設定ファイルは以下のようになります。

<VirtualHost *:80>
    ServerName nanapi.jp
    ProxyRequests Off

    ProxyPass / balancer://balancer/ timeout=10
    <Proxy balancer://balancer>
        BalancerMember http://serverA
        BalancerMember http://serverB
        BalancerMember http://serverC
    </Proxy> 
</VirtualHost>

社内リリースサーバの準備

そして複数あるWEBサーバのうち、1台だけリリース後のソースコードがcommitしてあるbranchに切り替えます。
この際、Server Cはサービスアウトをしておきます。設定ファイルでは、Balancer Memberから外しておくだけでOKです。

<VirtualHost *:80>
    ServerName nanapi.jp
    ProxyRequests Off

    ProxyPass / balancer://balancer/ timeout=10
    <Proxy balancer://balancer>
        BalancerMember http://serverA
        BalancerMember http://serverB
#        BalancerMember http://serverC
    </Proxy> 
</VirtualHost>

社内リリースを実現する

あとはこのサービスアウトしたサーバに社内からアクセスできるようにすればいいわけです。しかしながら/etc/hosts書き換えるとかProxy通しては面倒な手順です。何も考えずに切り替わっているべきです。
IPアドレスで判定するようにすれば、以下の方法でserverCへのアクセスをさせることができます。

<VirtualHost *:80>
    ServerName nanapi.jp
    ProxyRequests Off

    RewriteEngine On
    RewriteCond %{REMOTE_HOST} <OFFICE_IP_ADDR>
    RewriteRule (.*)   http://serverC$1 [P,L]
    ProxyPassReverse / http://serverC/

    ProxyPass / balancer://balancer/ timeout=10
    <Proxy balancer://balancer>
        BalancerMember http://serverA
        BalancerMember http://serverB
#        BalancerMember http://serverC
    </Proxy> 
</VirtualHost>

やっていることはシンプルで、RewriteでIPアドレスを判定し、serverCへProxyしています。これだけでカンタンに実現することができます。

現行（リニューアル前）を見れるようにしたいとき

とはいえ、リニューアル後しかいきなりみることができないのも不便です。というわけで切り替えられるような仕組みをいれてみました。
cookieで判定してあげればいいのでわり簡単にできます。apacheは以下のように設定をしました。

<VirtualHost *:80>
    ServerName nanapi.jp
    ProxyRequests Off

    RewriteEngine On
    RewriteCond %{REMOTE_HOST} <OFFICE_IP_ADDR>
    RewriteCond %{HTTP_COOKIE} !viewmode=old
    RewriteRule (.*)   http://serverC$1 [P,L]
    ProxyPassReverse / http://serverC/

    ProxyPass / balancer://balancer/ timeout=10
    <Proxy balancer://balancer>
        BalancerMember http://serverA
        BalancerMember http://serverB
#        BalancerMember http://serverC
    </Proxy> 
</VirtualHost>

その上で、cookieをくわせてあげる簡単なスクリプトを用意すればいいだけです。

<?php
if (isset($_GET['viewmode'])) {
  setcookie('viewmode', $_GET['viewmode'], time() + 60*60*24*30, '/');
}

こんなのを同じドメインのサーバにおいて、viewmodeという名前でcookieを食わせてあげればいいだけです。
これを用意しておくだけで、現行のソースコードがおいてあるサーバと、リニューアル後のソースコードがおいてあるサーバを簡単に行き来することができます。

社内リリース用のドキュメントを用意する

上記の準備をした上で、リリース後の意見を収集するためのフォームを用意しました。最後はすべてBTS(弊社ではbacklogを利用しています)に集約するわけですが、BTSに入れるのが面倒というだけで小さい意見を拾えないのは勿体無いものです。
そのために、今回はフォームを用意して簡単に意見を集めることができるようにしました。

なお、今回つかっているフォームはnanapiで独自開発したアンケートプラットフォームシステムを活用しています。

最後に

これだけ準備をして、1週間ちょっと社内から意見をもらったわけですが出てくる出てくる・・・社員だけでなくアルバイトのスタッフからも気軽に意見をもらえるのでリリースまえの調整がよくできたと思っています。

大幅なDBのスキーマ変更が伴うときには使いづらい手ですが、デザインやUI変更の場合は有効な手段だと思いますので、似たような構成でサービスを組んでいる人はぜひトライしてみてください。

※設定ファイルはBlogで記述するためにかなり簡素化しているため、本番運用している設定ファイルとは異なります。

スタッフ募集中！

nanapiではエンジニアを大募集しています！
nanapiではエンジニアを募集中！採用ページはこちらから

UNIX的なアレ

UNIX的なこととかいろいろ