DevOps ツール

発見のフェーズでは、DevOps チームはプロジェクトのスコープを調査して定義します。特に、ユーザー調査、目標の設定、成功の定義などのアクティビティが含まれます。

Mural や Miro などのツールによって、ソフトウェア チーム全体がアイデアを集めて調査を行えるようになります。Jira Product Discovery では、この情報が実用的なインプットに整理され、開発チームのためにアクションに優先順位が付けられます。優先順位付けする際には、ユーザーからのフィードバックのバックログも念頭に置く必要があります。

製品の検出は製品設計の最初のアクティビティであり、それが意思決定のベースラインになります。製品の検出時には、ユーザーの問題に関する重要な情報をすべて収集してから、その問題の解決策を提供できます。

“非同期ブレーンストーミング” を促進するツールを探すことをお勧めします。誰もがアイデア、戦略、目標、要件、ロードマップ、ドキュメントなど、何でも共有してコメントできることが重要です。

本番環境と同一の開発環境

Puppet と Chef は主に運用にメリットをもたらしますが、開発者は Kubernetes や Docker などのオープン ソース ツールを使用して、個々の開発環境をプロビジョニングします。本番環境の仮想的な使い捨てレプリカに対してコーディングを行うことで、より多くの作業を遂行できます。

"自分のマシンでは動作する" という言い分は疑念を生みますが、すべてのチーム メンバーがまったく同一の方法でプロビジョニングされた環境から作業するのであれば、それは事実であって疑われることはなくなります。

コードとしてのインフラストラクチャ

開発者がモジュラー式アプリケーションを作成するのは、信頼性が高く保守しやすいためです。その考え方を IT インフラストラクチャにも応用できないでしょうか。システムは常に変化しているため、この考え方をシステムに適用するのは難しい場合があります。そこで、この問題を回避するためにプロビジョニングにコードを使用します。

コードとしてのインフラストラクチャとは、再プロビジョニングのほうが修復よりも速く、一貫性と再現性が高いことを意味します。また、本番環境と同様の構成で、開発環境のバリエーションを簡単にスピンアップできることを意味します。プロビジョニング コードを適用してさらに再適用して、サーバーを既知のベースラインに配置できます。これはバージョン管理に保存できます。テスト、CI (継続的インテグレーション) への組み込み、ピアレビューが可能です。

組織のナレッジがコードで綺麗に体系化されると、ランブックや内部ドキュメンテーションの必要性は薄れます。そこで出現するのは、再現可能なプロセスと信頼性の高いシステムです。

ソース管理とコラボレーション コーディング

コードのソース管理は重要です。ソース管理ツールによってコードをさまざまなチェーンに保存できるため、すべての変更を確認して共有することで、より簡単にコラボレーションできます。変更諮問委員会を待ってから本番環境にデプロイするのではなく、プル リクエストを介してピア レビューを行うことによって、コードの品質とスループットを向上できます。

プル リクエストとは何かを説明すると、リポジトリ内の開発ブランチにプッシュした変更についてチームに伝えるものです。その後、チームは、変更案のレビューを行い、修正内容について議論してからメイン コード行にその内容を統合できます。プル リクエストはソフトウェアの品質を向上させるものであり、結果としてバグやインシデントの減少、運用コストの削減、迅速な開発につながります。

コード開発とデリバリーのさまざまな部分を接続できるように、ソース管理ツールは他のツールと統合する必要があります。これにより、機能のコードが本番環境で稼働するかどうかを確認できます。インシデントが発生した場合は、コードを取得してインシデントに焦点を当てられます。

継続的インテグレーションとは、共有リポジトリにコードを 1 日に数回チェックインして、その都度テストするプラクティスです。この方法では、問題を自動で早期検出して最も修正しやすいときに修正し、できるだけ早くユーザーに新機能をロール アウトできます。

プル リクエストによるコード レビューにはブランチの作成が必要ですが、この方法は大流行しています。DevOps North Star は、ブランチの数を減らして迅速に作成し、開発スピードを損なうことなくテストの厳密さを維持するワークフローです。

開発ブランチにテストを自動的に適用して、ブランチ構築が成功したときにメインにプッシュするオプションを備えたツールを探しましょう。さらに、シンプルな統合でチームからリアルタイムのチャット アラートを通じて、継続的なフィードバックを得られます。

Bitbucket Pipelines が、テストから本番環境までのコード処理の自動化にどのように役立つかをご確認ください。

自動テスト

テスト ツールは、探索的テスト、テスト管理、オーケストレーションなど、多くのニーズと機能に対応しています。ただし、DevOps ツールチェーンでは、自動化は不可欠な機能です。自動テストは、開発とテストのサイクルがスピードアップする点から、長期的に見れば投資に見合う価値があります。また、DevOps 環境では、これが重要である理由がもう 1 つあります。それは認知度です。

テストの自動化を早期に頻繁に行うことで、ソフトウェアの品質を向上させてリスクを軽減できます。開発チームは、UI テスト、セキュリティ スキャン、読み込みテストなどのいくつかの領域をカバーする自動テストを繰り返し実行できます。また、リスクのある領域の特定に役立つレポートと傾向グラフも生成されます。

リスクはソフトウェア開発につきものですが、予想できないものは緩和できません。運用チームのために、一緒に内容を詳しく見てみましょう。ウォールボードに対応したツールを探して、プロジェクトの関係者全員が特定のビルドまたはデプロイの結果にコメントできるようにします。運用チームが集中テストや探索的テストに参加しやすくするツールは特に役立ちます。

デプロイ ダッシュボード

ソフトウェアのリリースで最もストレスが大きい部分の 1 つは、今後のリリースのためにすべての変更、テスト、デプロイの情報を 1 か所にまとめることです。リリース前に最もしたくないことは、状況報告のための長いミーティングでしょう。そこでリリース ダッシュボードの出番です。

コード リポジトリやデプロイ ツールと統合された単一のダッシュボードを備えたツールを探します。ブランチ、ビルド、プル リクエスト、デプロイの警告を、すべて 1 か所で確認できるものを見つけましょう。

デプロイの自動化

すべてのアプリケーションと IT 環境で機能する自動デプロイの魔法レシピはありませんが、出発点として広く採用されているのは、Ruby または bash を使用して運用のランブックを cmd 実行可能スクリプトに変換することです。優れたエンジニアリング プラクティスは不可欠です。変数を使用してホスト名を除外します。環境ごとに異なるスクリプトやコードを維持するのは楽な作業ではありません (いずれにせよ半分は的外れです)。ユーティリティ メソッドまたはスクリプトを作成してコードの重複を回避し、スクリプトのピア レビューを行って健全性をチェックします。

まず、自動化を最も頻繁に使用することになる最下位レベルの環境へのデプロイを自動化し、次にそれを本番環境までのすべて段階にレプリケートします。少なくとも、これを実施することで環境間の相違点が強調され、その相違点を標準化するためのタスクのリストが生成されます。おまけに、自動化によってデプロイを標準化することにより、環境内および環境間の "サーバー ドリフト" が減少します。

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

DevOps チーム間のコラボレーションを円滑にする鍵は、全員が確実に同じ作業を見るようにすることです。インシデントが報告されるとどうなりますか? ソフトウェアの問題と結び付けられ、追跡可能ですか? 変更が行われた際に、リリースにリンクされていますか?

インシデントとソフトウェア開発プロジェクトを異なるシステムで追跡することほど、開発と運用のコラボレーションの妨げになるものはありません。問題を迅速に特定して修正できるように、インシデント、変更、問題、ソフトウェア プロジェクトを 1 つのプラットフォームにまとめるツールを見つけましょう。

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

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

スポット チェックであれば、手動でボックスを "トッピング" したり、テストで API を試したりすることでかまいません。ただし、アプリケーション (および環境) の傾向と全体的な健全性を把握するには、24 時間年中無休でデータをリッスンして記録するソフトウェアが必要です。継続的な可観測性は、成功する DevOps チームにとって重要な機能です。

グループ チャット クライアントと統合できるツールを探して、アラートがチームのルームまたはインシデントの専用ルームに直接送信されるようにします。

構築した製品が適切なものかどうかについて、既に顧客の声は届いています。必要なのはその意見に耳を傾けることです。継続的なフィードバックには、定期的にフィードバックを収集するための文化やプロセスに加えて、フィードバックからインサイトを引き出すためのツールが含まれます。継続的なフィードバックのプラクティスには、NPS データの収集とレビュー、解約アンケート、バグ レポート、サポート チケット、さらにはツイートも含まれます。DevOps の文化では、製品チーム全員がユーザーのコメントにアクセスできます。なぜなら、ユーザーのコメントはリリース計画から探索的テスト セッションまですべての指針として役立つからです。

チャット ツールをお気に入りのアンケート プラットフォームと統合して、NPS スタイルのフィードバックを実現するアプリケーションを探しましょう。Twitter や Facebook もチャットと統合して、リアルタイムのフィードバックを得られます。ソーシャル メディアからのフィードバックを詳しく調べるために、履歴データを使用してレポートを取得できるソーシャル メディア管理プラットフォームに投資する価値もあります。

フィードバックを分析して取り入れると、短期的には開発のペースが遅くなるように感じるかもしれませんが、長期的には効率が向上して誰も望んでいない新機能をリリースすることもなくなります。

アトラシアンでは、開発チームや運用チームが使用したいと思うツールとの統合に対応した DevOps ツールチェーンを用意することが重要であると考えています。そのため、171 社を超える主要なサードパーティ ベンダーと統合する DevOps プラットフォームを構築して、使用するツール全体で最適な意思決定を行えるようにしました。DevOps は単一のベンダーから購入するのではなく、構築すべきものです。

まずは、アトラシアンの DevOps ソリューションを無料でお試しください。