企業のDevOps変革を後押し

デベロッパーの作業成果物をを早い段階で高頻度で共有リポジトリに統合することで、バグを早期に発見し、すばやく解決につなげることができます。通常業務の一環として小ロットでの統合を行えば、ソフトウェアを高頻度でデリバリーできるようになるのです。ここでデベロッパーが頻繫なコード変更をメインリポジトリにコミットするのに活用できるバージョン管理ツールは多数あります。継続的インテグレーションサーバーはコード変更のバージョン管理システムのポーリング、最新コードの読込、さらにビルドを行います。

継続的インテグレーションの環境が整ったら、次は自動化テストです。それぞれのコードコミットはビルドスクリプトに統合され、自動化テストで検証されます。テストが自動化されていない場合、開発ベロシティがどれだけ加速化してもリリースサイクルは遅いまま、ということになりかねません。

ユニットテスト、受け入れテスト、統合テスト、さらには性能テストやセキュリティテストといった非機能テストまでも自動化することができます。ユニットテストと受け入れテストは並行して稼働するようにも設定できます。当社で非機能テストを自動化するために使うツールは   JMeter、NeoLoad、、Browsera等です。

デベロッパーワークステーションそのものにいくつかの自動化テストを構成することで、デベロッパーが自分の作業へのフィードバックをより速く受け取ることができます。例えば、RubyデベロッパーがFoodcriticからコード構造や構文に対するフィードバックを得ると同時に、Sonarlintがテスト自動化エンジニアが書いたSeleniumテストの解析をすることが可能になるのです。

ここで重要なのはテストの信頼性を確実なものにすることです。誤判定は自動化テストが解決する以上の問題を引き起こす可能性があるからです。当社では、一連の小規模で信頼性の高い自動化テストから入り、時間をかけてその対象を広げていくことを推奨しています。

ソフトウェアのビルドを自動化することができたら、次は環境（開発/テスト、ステージング、本番）のプロビジョニングと運用を自動化していきましょう。最新のプロビジョニング・構成管理ツールを利用すると、プログラムコードに従った環境設定とシステム構成の管理が可能になります（インフラ・アズ・ア・コード）。

構成ドリフトを発生させない一貫性のある信頼できるインフラをお探しなら、一度デプロイしたらサーバーの変更が無いイミュータブル・インフラモデルをおすすめします。このアプローチで変更が必要になると、適切な更新が行われた新規サーバーを割り当てて既存のものと置き換えます。

インフラ設定がコードに書き起こされている場合、バージョン管理システムと自動化テストを用いて環境プロビジョニングを行い、アプリケーションコードに使われるCI/CDパイプラインに統合することが可能です。Foodcritic for Chefやpuppet-lint for Puppetといったツールは環境構築に用いられたコードの分析に活用できます。こうしたプラクティスやセキュリティハードニングチェックを一連の自動化テストに加えても良いでしょう。

組織によってはインフラ・アズ・ア・コードとコンテナを組み合わせることも良いでしょう。これにより、アプリケーション環境からインフラ要件を切り離すことができるようになります。

コンテナは運用システムの構成要素（言語ランタイム、ライブラリ、システムファイル）をアプリケーションと結合させます。こうした構成要素はホスト環境を変えずに変更を加えることが可能であり、よって毎回特定の開発環境をセットアップする必要がありません。またコンテナは簡単に環境の複製ができ、仮想マシンに比べて軽量です。

継続的インテグレーションと自動化テストの設定ができたら、デプロイメント・パイプライン構築に進んでいきます。このパイプラインではあらゆる変更がリリース候補版になります。つまりコード変更の一つ一つがデプロイ可能なパッケージを作るビルドを実行するのです。自動化テスト（ユニットテスト、静的コード解析、受け入れテスト）はデベロッパーに迅速なフィードバックを提供するため行われます。こういったテスト（通常並行して実行される）に合格したパッケージは次の段階の一連のテスト（探索的テスト）を受け、最終的に本番環境にデプロイされていきます。万が一ビルドがある変更によって不合格となった場合、私たちはデプロイメント・パイプラインを構成してアンドンコードを引くことですべてのユーザに警告を発するとともに、エラーが解消されるまで、もしくはそのコミットがロールバックされパイプラインがグリーンの状態に戻るまでの間、それ以上の変更が統合されないようサポートいたします。

ここまでであなたのチームは高頻度な変更の実行、迅速なフィードバックの提供、そして本番環境へ自信をもってデプロイできるコードベースの維持ができるようになりました。成熟した継続的デリバリー環境があれば、お使いのコードベースはオンデマンドで一日に複数のデプロイを実行することができるようになります（グリーン環境）。つまりバグのないソフトウェアを高頻度でリリースできる状態にあるということです。

継続的デプロイメントは継続的デリバリーパイプラインのさらなる拡張をもたらし、実際のデプロイをも自動化させます。デプロイメント・パイプラインの最終段階において、コードベースは人の手を介すことなく自動でデプロイすることができるようになります。このようなシステムは新しい機能の迅速なリリースやユーザからのフィードバックをより速く集める支えとなります。

DevOps方式は、継続的インテグレーション、自動化テスト、継続的デプロイメントを機能に持つことで頻繫なコード変更を可能にします。そこで求められるのがお使いのアプリケーションコードや環境、オーケストレーション技術の総合的かつリアルタイムの監視です。アプリケーションの性能監視ツールの一つであるNew Relicは本番環境のアプリケーションの継続的監視に活用できます。チームが本番同様の環境で開発・テストを進めるようになるにつれ、継続的な監視範囲をステージング環境、テスト環境、さらには開発環境にまで拡大することもできます。

Devopsパイプラインの初期段階での自動化監視は、ラインのスムーズな流れを保つのに役立ちます。ビルド（開発の進捗状況）や自動化テスト、デプロイ、サーバーヘルス、アプリケーションログを監視する上で、得られたデータを中央に集約し分析や比較することが極めて重要となります。ここから導き出された指標をグラフに示したり統計的に分析することで、傾向の特定、問題の検知、システム停止の警告発信などを行うことができます。