成功しているエンジニアリング チームが実践している DevOps の原則と手法

この記事では、CircleCI がまとめた、高パフォーマンスの DevOps チームを実現するうえで不可欠な原則をガイド形式で紹介します。また、取り上げている関連リソースはいずれも、情報に基づいて判断を下し運用効率を最大限発揮する DevOps 文化を育むうえで役立ちますので、ぜひ参考にしてください。

DevOps の概要と DevOps が重要な理由

現在、DevOps に移行しようと試みているチームが数多くありますが、それには十分な理由があります。DevOps を導入すれば、市場の変化への対応速度を高められるからです。コードのデプロイの速度は速く、安全性は高くなり、本番環境を壊してしまう可能性は減ります。

しかし、DevOps への切り替えは、二者択一の問題ではありません。DevOps とは、運用の知識を開発に取り込もうというマインドセットです。もちろん、マインドセットとは別に、一連のプロセス、アプローチ、ツールの使用方法といったものもあります。

ツールを揃える前に DevOps チームの環境を整える

DevOps は、長い問題解決プロセスの最終段階です。DevOps 実現までの各段階では、さまざまなデジタル ツールを導入することになります。たとえば、CI/CD システム、テスト フレームワーク、モニタリング ツール、セキュリティ監査ツールなどです。しかし、これらのツールを導入する前に、DevOps マインドセットを定着させることが欠かせません。

DevOps に移行する前に、チームで以下の方針を徹底しましょう。

  1. 全員の認識を統一する。 DevOps 変革の目的について意識の統一を図ります。チームの全員から、解決しようとしている課題について同意を得て、足並みを揃えて課題解決に取り組むことを承諾してもらいます。
  2. 小さな取り組みから始める。 一夜にして理想的な DevOps チームを作り上げることはできません。まずは 1 つのチームから始めて、プロセス改革が組織内で有効かどうかを確認しましょう。
  3. 常に測定する。 改善計画を実行に移す前に、現状を正確に測定しておきます (開発サイクルに○時間かかっている、など)。そして、プロセス改革を実践したら、その効果を測定しましょう。
  4. なんでも一度に自動化しようとしない。 DevOps に関して、インフラストラクチャのプロビジョニングと構成管理をすべて自動化しなければならないとお考えの方もいらっしゃるようですが、これは誤解です(こうしたインフラストラクチャは “Infrastructure as Code (IaC)” と呼ばれます)。IaC 手法は、アプリケーションを大規模にサポートするためのものです。まずアプリケーションのビルドとテストの自動化を試してから、高度なデプロイ シナリオを自動化しましょう。

DevOps の文化とツールを詳しく知りたい方は、「DevOps への移行: 本当に必要なツールとは」(英語) を参照してください。

Infrastructure as Code の詳細に興味がある方は、「Infrastructure as Code (IaC) の使用方法」をご覧ください。

管理職から DevOps に対する同意を得る

管理職から新しい DevOps ツールに対する同意を引き出すのは、簡単ではないかもしれません。以下に、新しいツールを承認してもらうためのアプローチのヒントを紹介します。

  1. ツールではなく、課題を強調する。 話し合いを始める前に、要対処事項を明らかにしておく必要があります。行動につながるインサイトが得られないミーティングに、時間を割こうとする管理職はいません。
  2. ニーズを裏付ける関連データを用意する。 データ生成のプロである開発者として、管理職に要望を伝える際には、具体的な統計データを示すようにしましょう。
  3. チーム内で最も反対していそうなメンバーから賛同を得る。 ツールの導入により仕事に影響を受けるメンバーと、新しいツールに対して意見を持っていそうなメンバーを、コミュニケーションに加えることが重要です。
  4. ツールのデモを行い、質問を受ける。 ツール導入の過程で問題が発生しそうかどうかをチーム メンバーに質問します。

管理職へのアプローチ方法に関する詳細とヒントをもっと知りたい方は、「管理職から DevOps ツールに対する同意を得る方法」(英語) を参照してください。

DevOps をセキュリティ強化に活用する

開発環境と本番環境から分析キーやコード署名の認証情報まで、さまざまなリソースにインフラストラクチャからアクセスできる状況では、CI/CD パイプラインがテクノロジー スタックの重要な要素になります。パイプラインからアクセス可能なリソース (セキュア シークレット、非公開コード、データベースなど) が増えるほど、CI/CD システムをセキュアに保つ重要性が高まります。

DevSecOps を導入し CI/CD パイプラインをセキュアにするには、以下に示す 3 カテゴリのセキュリティのベスト プラクティスを実践することをお勧めします。

  1. パイプライン設定ファイルをセキュアにする - CI/CD パイプラインの設定ファイルを使用して、セキュリティ問題が発生するリスクを抑えます (CircleCI Orbs) についての記事を参照)。
  2. コードと Git の履歴を分析する - 時間をとって、コードベースにコミットされたシークレットを特定します。見付かったシークレットは非アクティブ化して置き換えましょう。
  3. セキュリティ ポリシーを適用する - セキュリティ問題の中には、既知の脆弱性を基に統計的にチェックすればよいものだけでなく、企業固有の問題もあります。そのような問題は、ポリシーを明文化して対処する必要があります。

DevSecOps 手法の採用の詳細については、「CI/CD のセキュリティと DevSecOps の完全ガイド」(英語) を参照してください。

有意義な DevOps 目標をチームに設定する

チームを成功に導くうえでは、測定すべき適切な DevOps メトリクスを見付けることがきわめて重要です。すべてのチームが追求するべき唯一の基準は存在しませんが、CircleCI のデータと、CircleCI プラットフォームで認められた 2020 年の DevOps ソフトウェアの傾向を見てみれば、チームの目標として合理的なベンチマークはいくつか存在しているのがわかります。

参考: 4 つの主要ベンチマークでエンジニアリング チームの DevOps の成功度を測定する方法

最終的に価値があるのは、”理想” を達成することではなく、これらのメトリクスに基づいて自社のベースラインを測定し、徐々に改善していくことです。

2020 年版ソフトウェア デリバリーに関する現状調査:データに基づくエンジニアリング チーム向けベンチマーク』をご覧になり、チームでソフトウェア デリバリーの改革をさらに推進する方法をご確認ください。レポートはこちらからダウンロード可能です。