Coolblueの継続的デプロイメント

継続的デプロイメントは結果的に，より高い責任感とデプロイメントの品質向上をもたらす — CoolblueのテクニカルパスファインダであるPaul de Raaij氏は，このように主張する。コーディング標準はコードベースの混乱を防止し，自動化されたインスペクションは退屈で単純なチェック作業に効果がある。そして手作業によるチェックは，ロジックやコードの利用の妥当性のチェックに最適な方法だ。

De Raaji氏はブログ記事“continuous deployment of our software”の中で，Coolblueにおけるデプロイメント方法について次のように書いている。

ソフトウェアを開発するだけでは不十分です。実際の運用に移す必要がありますし，品質がよく，問題のないソフトウェアを提供していることも確認しなくてはなりません。

Paul de Raaji氏はAgile and Software Architecture Symposium 2016で，Coolblueの継続的デプロイメントについて講演を行なう予定だ。InfoQは氏にインタビューして，Coolblueでのデプロイメント，継続的デリバリのメリットと落とし穴，品質保証のためのテクニックとプラクティス，コーディング標準，アプリケーション監視や，Coolblueが直面している課題と対処方法などについて聞いた。

InfoQ: Coolblueが開発者自身によるデプロイメントを認めた理由は何ですか？

Paul de Raaij: できる限り早く，ソフトウェアを運用に提供したいと思ったからです。それによって，機能に対するフィードバックを早く得られます。そうしたフォードバックから学んだり，必要ならば別の方法を選ぶことが可能になるのです。また当社では，製品に対する全権を開発チームに委ねるようにもしています。リリースエンジニアを例にとれば，責任の移行が完全な所有権を持つための鍵になります。あなたがコードを壊したのであれば，それを修正するのはあなた自身です。他の誰かがトラブルの責任を取ってくれるということはありません。これは結果として，より高い責任感とデプロイメントの品質向上につながります。

InfoQ: 現在はどのようなデプロイメントを行なっているのですか？

De Raaij: 短時間で完全に答えるのは難しいので，概要を短く説明します — 私たちは分散バージョニングシステムとしてGITを使い，gitflowワークフローを利用しています。自分のコードを有効にしたい開発者は，プルリクエストを作成します。このプルリクエストはまず自動的に，次に手作業でレビューされます。すべてがOKであれば，ソフトウェアは自動的にパッケージされ，開発サーバと受入テストのサーバに配置されます。あとはボタンを手動でプッシュすれば，デプロイメントが運用にプッシュされます。もちろんその間には，もっと多くのステップがあります。詳細はASASのセッションで説明する予定です。

InfoQ: 継続的デリバリのメリットは何でしょう？

De Raaij: メリットはたくさんあります。まず第一に，正しく実行されることで，ソフトウェアがサーバにデプロイ可能であることを証明できます。さまざまな検査ツールを使って自動的に検査されることで，一定の品質を担保することが可能になります。回帰テストが適切に設定されていれば，旧機能がデプロイメント後も動作することも保証できます。

InfoQ: 注意すべき点は？

De Raaij: 最終的に残るのは，人手によって設定される手作業プロセスです。適切な方法を定義するのは簡単でも，間違いの起こる可能性が残っているからです。従ってCIプロセスの設定に関しては，十分な考慮が必要です。例えばオンラインサービス(GitHubなど)を利用している場合，それが停止するとプロセスにどのような影響があるのか？

開発チームの規模についても考えなくてはなりません。500人の開発者が同じプロセスで作業する場合と，数人がアップデートを行なうだけの場合とでは，CIパイプラインの動作も違ったものになる可能性があります。ですから，ソリューションがどの程度までスケールアップしなくてはならないのかを，事前に考えておく必要があります。コードインスペクションのエージェント追加は簡単か？プルリクエストの検査終了まで30分待つことは可能か否か？

InfoQ: Coolblueでは品質を保証するために，どういったテクニックやプラクティスを，どのような理由で使用しているのでしょうか？

De Raaij: 利用している手法はさまざまです。インスペクションにも，手作業のものと自動化されたものがあります。自動化されたインスペクションは，コードチェック(lint)やコーディング基準の確認，回帰テストの実行といった，退屈で単純なチェックを行なうのに最適ですし，手作業によるチェックは，ロジックやコードの使い方が適切であるかをチェックしたり，プログラムされた内容がユースケースを完全に解決しているかを確認するのに向いています。

InfoQ: コーディング基準はどのように使用しているのでしょうか？それによってどのようなメリットがありますか？

De Raaij: コーディング基準は，コードベースの混乱を回避する手段として重要です。すべての開発者がインデントやスペースの挿入，命名を独自のルールで行なえば，コードはすぐに無秩序状態になります。これはソフトウェアや提供物の品質に大きく影響するだけはありません。開発者の作業も難しくなりますし，やがては不満や苛立ちも高まるでしょう。

当社が使用しているコーディング基準は，おもに業界標準で定義されたものです。例えばPHPでは，PSRが定義した標準を中心として，独自に少し手を加えています。

InfoQ: アプリケーションの監視はどのように行なっていますか？

De Raaij: 多数のツールを組み合わせて使用しています。マシンの技術的な監視については，アプリケーション監視の主力として，Nagiosに多くを依存しています。Nagiosはマシンの状態やデーモンの稼働状況に特化した監視ツールです。私たちにとって監視は，ソフトウェアの全般的状況におけるキーとなるものです。当社のアプリケーションにはそれぞれ，ヘルスチェックや洞察，分析を行なうためのメトリクスが定義されています。これらのメトリクスは，StatsDなどのアグリゲータを経由してDatadogに送られます。メトリクス以外にも，ELKスタックを使ったログの詳細な解析を行なっています。

InfoQ: Coolblueが直面している課題はどのようなもので，それに対してどう対処しようとしていますか？

De Raaij: 当社にとって，完全な継続的デリバリが大きな項目です。すでにかなりの進歩を遂げてはいますが，私たちの進む先には，真の自動デプロイメントの実現を妨げる障害があります。当社のソフトウェア環境で大きな障害となっているのは，システムのデータマイグレーションに関する扱いです。この問題が解決できれば，本当の意味での継続的デプロイメントに近づくことができます。

Agile and Software Architecture Symposium 2016は9月28日に，オランダのアーネムにあるGelreDomeで開催される。

ASASは，技術的リーダやソフトウェアアーキテクト，ビジネスアナリスト，エンジニアリングディレクタといった人たちが，ユーザに適したソフトウェアソリューションを提供するためのよりよい方法について学び，議論することを目的とした，実践的ソリューション中心のカンファレンスです。

InfoQはこのカンファレンスの様子をQ&Aや要約，アーティクルでお伝えする予定だ。