オールアバウトの@takkyです。

オールアバウトはサイト開設15年とWebメディアとしては長い歴史を持っています。そのため、リリースフローも時代によって様変わりしてきました。
今回はオールアバウトのリリースフローがどのように変わってきたか
今後どのように変えていくかについて書いていきたいと思います。

リリースフローの変遷

2014年以前は私の入社前なので伝聞や社内資料を漁ったものなので若干正確じゃないところでもあります。
また、図はリリースフローをかなり簡素化したものになってます。
詳しいフローは本記事の後半に記載しています。

~2011年頃

本番リリースは手動でFTPアップロードというリリースを行っていたようです。
また、ソース管理もディレクトリコピー管理で行っていたようです。
そのような背景もありこの時代は古いソースで上書きリリースをしてしまうなど事故が多かったようです。
f:id:allabout-techblog:20160620170802p:plain

一部のプロジェクトでは、VSSを導入していたものもあるようです。
Microsoft Visual SourceSafe - Wikipedia

2011年頃

この時期にSubversionを導入しはじめたようです。
ディレクトリ管理からSubversion管理にすることでソース管理自体はシンプルにできるようになりました。
しかし、大型のリニューアル時のマージ漏れなどで事故はあったようです。

2011〜2013年頃？

インフラチームが本番サーバに入りリリース用のスクリプトを実行していたようです。
インフラチームがリリーススクリプトを実行しないといけないという問題はありましたが、
FTPアップロードよりはだいぶマシになってきたようです。
f:id:allabout-techblog:20160620170859p:plain

2013年秋頃？

Jenkinsを導入しはじめました。
インフラチームが本番サーバに入る必要がなくスクリプトの実行ができていました。
しかし、リリース作業は開発者からの依頼によりインフラチームが行っていました。
ロールバックがあった場合、インフラチームが対応しなければいけないため、開発者・インフラ担当者と2倍の工数がかかっていたようです。
f:id:allabout-techblog:20160620170957p:plain

2014年夏

ちょうど新卒入社半年後だったこともあり、
Subversion -> Git(bitbucket)への移行の担当者として、bitbucketへの移行を行いました。
これにより、いまでは当たり前となっているgitを利用した開発ができるようになりました。
移行直後はgitのフローに慣れていないこともあり、masterへの直pushや誤マージなどで、事故になりそうなこともありました。
最近はgitのフローに慣れてきたからかgitが起因の事故もほぼなくなってきています。

2014年冬

Jenkinsによる開発者のリリースが開放され、開発者がリリースを行えるようになりました。
これによりリリース時のインフラチームがリリース作業から解放され負担が少なくなりました。
また、デプロイの効率も良くなり日別のデプロイ数が約3倍になりました。
f:id:allabout-techblog:20160627150231p:plain

2016年春

Wercker+DeployerによるCIを導入し、 CIツールであるWerckerを用いてテストの自動化やデプロイツールであるDeployerを用いて、
確認環境や本番環境への自動化を行うことができました。
Jenkins時代はインフラチームがリリースの設定を行うという点でインフラチームの負担となっていました。
また、Jenkins時代がブラックボックス化してきており、後々技術的負債になってしまうのではないかという懸念点もありました。
Wercker+Deployerによるリリースフローでは開発者がリリースの設定も行うことによりもっと早くデプロイが可能になっていくと考えられます。

f:id:allabout-techblog:20160620171200p:plain

このようにソース管理はディレクトリ管理 -> Git管理
リリースはFTP手動アップロードから開発者がリリースへと変わってきました。

上記ではかなりざっくりリリースフローを紹介しましたが、以下で2014年冬頃のJenkinsを利用した開発フローと、
今年はじめたWercker+Deployerでのリリースフローについて記載したいと思います。

2014冬Jenkinsを利用した開発フロー

基本的にはGitHub-flowで行っています。
Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）：プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - ＠IT f:id:allabout-techblog:20160620171539p:plain masterへマージ後手動でstaging環境にてgit pull origin masterを行い、デプロイします。
必要があればcomposer updateなど行います。
staging環境でのブラウザテストなどを行います。
次にPrimary Front: PF環境（本番と環境がほぼ同一なリリース事前確認環境）にrsyncでstagingのソースを展開します。
PF環境では本番環境のDBを参照しているため、本番と同一データで問題ないかのチェックを行います。

PF環境でのチェックが終わり次第Jenkins経由でリリーススクリプトを動作させ本番環境へデプロイします。
リリーススクリプトは、pf環境にあるファイルをtarで圧縮し各サーバで展開していました。

このフローの欠点は3つあり、
1. stg環境/pf環境に入ってリリース準備を行うのが手間であること。
2. stg環境でテスト時にソースを直接変更してしまい、それがPF、本番へデプロイされて事故が起きてしまうこと。
3. Jenkinsはインフラチームが管理しており、開発者側から見るとブラックボックス化してしまっている。また、ソース管理されていなかったこと。
がありました。

上記の欠点を解消するためにオールアバウトではWerckerとDeployerを用いてのリリースフローに徐々に切り替えています。

WerckerとDeployerを用いてのリリースフロー

WerckerやDeployerについては、次回に詳しく書くこととしてWercker+Deployerを用いたリリースフローについて記載します。

リリースフロー

f:id:allabout-techblog:20160620171628p:plain 青矢印がstaging環境へのリリースフロー
赤矢印がpf環境へのリリースフロー
黒矢印が本番環境へのリリースフロー

GitHub-flowを若干拡張したような、Git-flowを簡易化したようなフローを使っています。

1.stg用のbranchにマージされたタイミングでWerckerが自動実行され、staging環境へ自動デプロイされます。
staging環境への自動デプロイはWercker上からDeployerサーバに接続してDeployerを実行しています。

2.master branchへマージされたタイミングでWerckerが自動実行されpf環境へ自動デプロイされます。

3.Wercker上から本番反映ボタンを押すと、Wercker上からDeployerサーバに接続してDeployerを実行しrsyncでデプロイをしています。
Deployerにはrsyncのレシピが用意されているので特に大きく設定を加えずにデプロイスクリプトを使用することができます。

これにより、開発者はSTG/PF環境に入らずデプロイが可能になりました。
Werckerの設定はWeb上で行えるため、容易に開発者が設定できます。
DeployerのスクリプトはPHPで書かれているためこちらも準備することが簡単にできます。
定常的なリリース作業や新規アプリケーションの構築時に素早くできることを期待しています。