適切な DevOps ツールの選び方

率直に申し上げましょう : この世の中のどのようなツールでも、魔法のようにDevOps (あるいはアジャイルやリーン) を作り上げることはできません。DevOps は開発と運用チーム間のコラボレーションとコミュニケーションを提唱するものであり、魔法のレシピというよりは文化的転換だと言えるでしょう。

ただし、オートメーションやチーム間のコラボレーションを支える ツールやテクノロジーは存在します。私たちはよく、アトラシアンにおける DevOps 的作業方法をサポートするにあたって、どのツールを利用しているのかという質問を受けます(自社製品以外で)。そこで、DevOps ツールの購入にあたっての要点に加え、私たちのチームが使用しているツールを示す購入者向け手引きを整理してみました。

多くのツールは、開発サイクルのあらゆるフェーズに何らかの方法で関わっているものの、各フェーズで主要な役割を果たす単一のツールというものは、私たちが知っている限りでは存在しません。そのため、DevOps ツールについて検討する際はフェーズごとにかみ砕いて捉えると便利です。ここでは、次のように細かく見てみましょう:計画、ビルド、継続的インテグレーション、デプロイ、オペレーション、継続的フィードバック。

DevOps-Tools

  1. 計画 (PLAN)
  2. ビルド (BUILD)
  3. 継続的インテグレーション (CONTINUOUS INTEGRATION)
  4. デプロイ (DEPLOY)
  5. オペレーション (OPERATE)
  6. 継続的フィードバック (CONTINUOUS FEEDBACK)

1. 計画

ビジョンとデザインのコラボレーションを行う

アジャイルハンドブックからの引用になりますが、お勧めするのはあなたの開発チームがイテレーションでプランニングできるツールです。こうすることで、ユーザーからより早く学習できるほか、そのフィードバックを元に製品の最適化を図ることができます。スプリントプランニング機能を備えたツールを探しましょう。

もう一つの優れた習慣としては、ユーザーフィードバックを継続的に収集して、これを実行可能な入力データへと整理し、開発チーム向けにこれらのアクションに優先順位を付ける方法が挙げられます。いうならば、「非同時性ブレインストーミング」を促すツールを探しましょう。アイディア、戦略、目標、要件、ロードマップ、ドキュメンテーションに至るまで、全員があらゆる内容を共有し、これにコメントできることが大事です。

あと、インテグレーションも忘れてはいけません。フィーチャーもしくはプロジェクトのスコープを設定する場合はいつでも、開発バックログのユーザーストーリーに変換する必要があります。

このフェーズの詳細に関しては、アトラシアンの製品マネージャーたちのバックログ グルーミングと優先化に関する投稿を参照してください。

私たちが使用するツール: ConfluenceHipChatJIRA Software

2. ビルド

開発向けに環境を用意

Puppet と Chef は主に運用チームに恩恵をもたらす一方、開発者は Docker などのツールを用いることで、個別の開発環境のプロビジョニングを行います。本番環境の仮想かつ使い捨て可能なレプリカに対してコーディングすることで、より多くの作業を達成できます。

クラスパスで何か不思議なことが起きていますか?Maven のインストールが突如崩れましたか?インフラストラクチャをコードとして処理すると、修復するよりも再プロビジョニングした方が早いことを意味する上、より確実でもあります。また、お使いの開発環境のバリエーションをスピンアップすることも可能です。

チーム全体が同様にプロビジョニングされた環境から作業する場合、「私の端末では問題なし!」というコメントの面白みは失われてしまいますが、これは当然のことだからです (こうなると、この発言からは変な印象しか受けません) 。

私たちが使用するツール: Docker

インフラストラクチャをコードとして処理

開発者がモジュラー アプリケーションを作成するのは、それがより確実で維持可能だからです。ならば、この思考をIT インフラに広げても問題はないはずです。

これをシステムに適用するのが難しい理由として、常に変化している点が挙げられます。そこで、プロビジョニング用にコードを用いることで対応します。プロビジョニングコードは、ベアメタルにも適用できるほか、再適用することでサーバーをベースラインに戻すことも可能です。

これは、バージョンコントロールに保管することが可能です。テストすることも、CI (継続的インテグレーション) に取り込むことも可能です。ピア (同僚) レビューも OK。色々と可能です。

組織のナレッジがコード化された場合、ランブックや社内向けドキュメントの必要性が薄れます。そこで登場するのは、反復可能なプロセスと確実なシステムの存在です。こうして、おしゃべりが減り、どんどん作業が進みます。

私たちが使用するツール: BambooBitbucketChefDockerPuppet

共同コーディング

本番環境へのデプロイまでの間、変更承認委員会の判断を待つ代わりに、プルリクエストからのピアレビューでコード品質とスループットを改善することができます。

プルリクエストとは何でしょうか?プルリクエストは、あなたのリポジトリ内の開発ブランチにプッシュした変更内容について、チームに伝える役割を果たします。これによって、チームは提案された変更内容を検証し、メインラインに統合する前に修正について考察することができます。

プルリクエストの詳細については、このチュートリアルを参照してください

私たちが使用するツール: Bitbucket

率直に申し上げましょう: どのようなツールも、魔法のように DevOps を作り上げることはできません。


3. 継続的インテグレーション

継続的インテグレーション

継続的インテグレーションとは、一日に数回、共有リポジトリでコードをテストして確認する習慣を指します。こうすることで、問題を早期に検出し、修復が簡単な段階で修復し、出来るだけ早く真新しいフィーチャーをユーザーに届けることができます。

ブランチをマージするワークフローが大人気のため (当然ですね!)、開発スピードを犠牲にすることなくテストの厳格さを保つには、複数のブランチを伴う環境でのCIの実行という面倒を取り除くツールが重要となります。

ツールを探す際は、テストを自動的に開発ブランチに適用させ、ブランチのビルドが成功した場合にマスターにプッシュする選択肢を選べるものを見つけましょう。このほかにもシンプルなインテグレーションでは、チームのチャットツールのリアルタイムアラートを得ることができます。

さらに詳しく調べるには、フィーチャーブランチと Bamboo で CI を成功させるを参照してください。

私たちが使用するツール: BambooHipChat

自動テスト

自動テストでは、長期的な開発とテストサイクルのスピードを速めることで、経時的な効果を得ることができます。さらに、DevOps 環境においてはもう一つ、アウェアネスという理由から重要性を抱えています。

開発チームの構築内容に向けて準備を整え、これをサポートするにあたって、運用チームは何がどの程度綿密にテストされているかを明白に理解することが重要です。自動テストは手動テストとは異なり、毎回正確かつ厳正に実行されます。また、レポートや動向グラフを生成するため、リスクの高いエリアを特定しやすくなります。

リスクとは、ソフトウェアにおいて現実に存在するものですが、予測不能なものを緩和させることはできません。運用チームに手を貸して、彼らにも内部の状況を見せてあげましょう。ウォールボードに対応したツールを探して、プロジェクトに関与している全員が特定のビルドやデプロイ結果にコメントできるようにしましょう。Blitz テストや探索的テストに運用チームを組み込みやすいツールは、特にお勧めです。

私たちが使用するツール: BambooBitbucketCapture for JIRA

4. デプロイ

リリースダッシュボード

ソフトウェア出荷にあたって最も頭の痛くなる点の一つが、全ての変更、テスト、デプロイ情報を最新リリースで一箇所にまとめるという作業です。リリース前には、誰もステータスを報告する長いミーティングなどしたくありません。ここで役立つのが、リリースダッシュボードです。

ツールを探す際は、使用しているコードリポジトリやデプロイメントツールと統合された、単一のダッシュボードを備えたツールを探しましょう。ブランチ、ビルド、プルリクエスト、デプロイの警告に関する完全な可視性を、一カ所で提供するツールを見つけましょう。

私たちが使用するツール: JIRA Software

自動デプロイメント

全てのアプリケーションと IT 環境で動作する、自動デプロイメントの魔法のレシピは存在しません。しかし、Ruby あるいは Bash を用いることで、運用チームのランブックをコマンドプロンプトから実行可能なスクリプトに変換するというのは一般的な第一歩です。必要不可欠なのは、優れたエンジニアリング習慣です。変数を用いて、ホスト名をくくり出しましょう。各環境向けに固有のスクリプトやコードを保つのでは、面白みがありません (その上、要点の半分以上が損なわれてしまいます )。重複コードを避けるため、ユーティリティ メソッドもしくはスクリプトを作成しましょう。また、サニティーチェックを実践するにあたって、スクリプトのピアレビューも行いましょう。

最初は、オートメーションを最も頻繁に使用する、最も下位の環境に対して自動デプロイを行ってみましょう。次に、その内容を本番環境に至るまで全て複製します。この練習では少なくとも、使用している環境の差異を浮き彫りにして、これらの標準化に向けた作業のリストを生成します。さらに、オートメーションを通じてデプロイを標準化すると、環境内および環境間の「サーバードリフト」を減らすことができます。

Puppet や Chef などのプロビジョニングツールは、環境の標準化にあたっての手間を減らします。また、自動デプロイをサポートするツールは沢山あります。アトラシアンの Bamboo は、複雑なデプロイメントも一つ一つ調整することで、各環境の履歴に対する可視性を提供します。

Puppet もしくは Chef を HipChat と合わせて使用することで、チャットルームからデプロイメントを制御することが可能です。多少のグーグル検索を行えば、目的の用途と予算に適したものをきっと見つけることができるでしょう。

私たちが使用するツール: AWSBambooHipChatPuppet

5. オペレーション

アプリケーションとサーバーパフォーマンスの監視

自動化を必要とする監視には、サーバー監視とアプリケーションパフォーマンス監視の二種類があります。

スポットチェックを行う場合は、手動でボックスを「トッピング」させるか、API をテストするだけで事が済みます。しかし、お使いのアプリケーション(および環境)の全体的な健全性や動向を把握するには、データを 24 時間週 7 日記録して、監視するソフトウェアが必要になります。

もちろん、そのためのアプリは存在します。しかも、沢山。人気の New Relic、Splunk、Nagios などは二種類の監視を扱います。ツールを探す際は、お使いのグループチャット クライアントと統合できるものを見つけましょう。これによって、アラートはチームのルームあるいはインシデント向け専用ルームに直接届きます。

私たちが使用するツール: BigPandaHipChatHostedGraphiteNagiosNew Relic, Pager DutyPingdomSplunk

コミュニケーションとスウォーミング

文化的転換に向けた第一歩となるのがチーム横断式のコミュニケーションであり、チャットツールはリアルタイムでこれを促進します。多くのチャットツールには専用ルームが備わっているため、インシデントが発生したら専門家が群れ出て、より迅速に修正することが可能です。

また、アップタイムの最大化を図れるよう、常に注意することも重要です。拡張可能かつ監視ツールと統合可能なチャットツールを見つけることで、重要なサービス低下アラートを見落とさないようにしましょう。
最も人気の高い企業は、自社のオフィスの外へとコミュニケーションを広げています。困った事態になった際はユーザーに通知でき、インシデントの解決状況に関する最新情報を伝えられるツールを見つけましょう。

詳しくは、 アトラシアンにおけるインシデントの対応方法を参照してください。

私たちが使用するツール: BigPanda, DataDogHipChatNew RelicPager DutyStatusPage

インシデント、変更、問題追跡

チーム間のコラボレーションを解き放つにあたっては、全員が同じ作業内容を確認できるようにすることが鍵となります。インシデントが報告された場合、どうなるのでしょうか?それは、ソフトウェア問題と関連していて、追跡可能なのでしょうか?変更が施された場合は、リリースに反映されるのでしょうか?

開発チームとオペレーションズチーム間のコラボレーションを阻害する一番の理由となるのが、インシデントやソフトウェア問題を異なるシステム上で追跡する行為です。ツールを探す際は、インシデント、変更内容、問題、ソフトウェア問題を単一のプラットフォーム上にまとめることで、問題の特定と修正を速やかに実行できるものを見つけましょう。

私たちが使用するツール: JIRA Service DeskJIRA Software

6. 継続的フィードバック

ユーザーフィードバックを通じてより良い商品を

構築した製品が正しいかどうか、顧客はすでに意見を発信しています。必要なのは、彼らの声に耳を傾けることです。こうした情報には、NPS データ、チャーン率調査、バグレポート、サポートチケット、さらにはツイートまでもが含まれます。DevOps 文化においては、ユーザーコメントがリリースプランニングから探索的テストセッションに至るあらゆる内容の先導役を務めるため、製品チームの全員がこれにアクセスできる必要があります。

お使いのチャットツールをお気に入りの調査プラットフォームと統合して、NPS フィードバックを得られるアプリケーションを見つけましょう。ツイッターあるいは Facebook も、チャットと統合してリアルタイムのフィードバックを得ることができます。ソーシャルメディア発のフィードバックをより深く掘り下げる場合は、履歴データを元にレポートを引き出せるソーシャルメディア管理プラットフォームへの投資も価値があるでしょう。

フィードバックの分析と取り込みは、短期的には開発ペースを落としているように感じることがあるかもしれません。しかし、長期的な目線で考えれば、誰も必要としていない新しいフィーチャーをリリースするよりも効率的なのです。

私たちが使用するツール: GetFeedback, HipChatJIRA Service Desk, Pendo, SurveyMonkeyHootsuite

DevOps ツールコレクションを完ぺきにする

アトラシアンが作成しているツールは、開発サイクルの各フェーズにおいてチーム横断式のコラボレーションをサポートします。これまでに見てきた通り、私たちは同僚が構築したアドオンやスタンドアロン型ツールを用いることで、自分たちの DevOps ツールスタックを拡大しています。

DevOps-Tools-Atlassian

小さな企業では、一つのチームが全開発サイクルを担当するかもしれません。大きな企業では、部門ごとに担当が分かれています。いずれにせよ、DevOps とは部門横断型あるいは単一のチーム内のどちらであるにせよ、サイロを細かく分割してライフサイクルの速度を上げ、オートメーションを高めて、シームレスなコラボレーションを実現することにあります。

適切な DevOps ツールの選択で何よりも重要となるのが、現在使用しているソフトウェアと IT オペレーションプロセスを精査し、改善点を判断することです。今回のリストで、皆さんを正しい方向に導くことができたならば幸いです。上手くいくことを願っています!

ツールのことが頭から離れませんか? (よく分かります、その気持ち!) 以下をクリックして、アトラシアンスイートの詳細とその DevOps のサポート方法を参照してください。

DevOps 向けツールの詳細を見る

 

この投稿は、役に立ちましたか?同じ DevOps ファンの皆さんも参考にできるよう、お好みのソーシャルネットワークでシェアしてください!


*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。 *原文 : 2016 年 3 月 31 日 “How to choose the right DevOps tools