DevOps のベスト プラクティス

DevOps を実装するためのベスト プラクティス

アジャイルプロジェクト管理

アジャイルはプロジェクト管理とソフトウェア開発の反復的なアプローチであり、チームがより迅速により問題が少ない状態で顧客に価値を提供できるようにサポートします。アジャイル チームでは、1 回の大規模リリース日を待つのではなく、より小さな変化で何度も成果を提供することに重点を置いています。要件、計画、結果は継続的に評価されるため、チームはフィードバックに対応して必要に応じて方向転換できます。

アジャイル プロジェクト管理の重要な概念は次のとおりです。

• To Do、進行中、コード レビュー、完了の 4 つの段階を含むワークフローから始めます。ワークフローの詳細についてご参照ください。
• チームは大規模なプロジェクトをより小さなタスクに分割して、進捗に応じてニーズやスコープの変化に対応する必要があります。業務のスコープ管理と体系化にエピック、ストーリー、テーマを使用する方法についてご参照ください。
• インクリメンタルな作業の計画、追跡、測定はどのように行いますか? スクラムとカンバンは、アジャイル手法を実践するチームのコア フレームワークです。

​​​​​​​CI/CD によるシフト レフト

「シフト レフト」するチームは、コード開発プロセスの早期にテストを取り入れます。複数の変更を個別のテスト チームや QA チームに送信する代わりに、コーディング プロセス全体を通じてさまざまなテストを実施するので、開発者はコードベースで作業しながら、関連するセクションでバグの修正やコード品質の改善を行えます。継続的インテグレーションと継続的なデリバリー (CI/CD)、デプロイの実践により、シフト レフトが可能なります。CI/CD の詳細についてご参照ください。

​​​​​​​適正なツールで構築

DevOps ツールチェーンには、DevOps ライフサイクルの各段階に適したツールと、ソフトウェアの品質とデリバリーの速度を向上させるための重要な機能が必要です。DevOps ツールを選択する方法の詳細についてご参照の上、DevOps ライフサイクルの各段階に必要な機能をご確認ください。

​​​​​​​自動化の実装

継続的インテグレーションとデリバリーによって、開発者はコードをメイン リポジトリに定期的にマージできます。指定された期間でのバッチ処理から頻繁なコミットまで、コードを手動でチェックする代わりに CI/CD はこのプロセスを自動化します。CI/CD に加えて、自動テストは DevOps プラクティスを成功させるために不可欠です。自動テストには、エンドツーエンドのテスト、ユニット テスト、統合テスト、性能テストが含まれる場合があります。ソフトウェア開発プロセスへの自動化の組み込みに関する詳細についてご参照ください。自動化の詳細についてご参照ください。

​​​​​​​DevOps パイプラインとアプリケーションを監視

DevOps パイプラインを監視して、壊れているビルドや失敗したテストが原因で不要な遅延が発生しないようにすることが重要です。自動化は開発のスピードを飛躍的に向上させますが、自動化されたプロセスに障害が生じてそれについて誰もわからない場合は、手動で作業を行うほうがよいでしょう。同様に、実稼働アプリケーションを監視して、顧客から指摘される前に障害やパフォーマンス不足を特定することが重要です。

​​​​​​​可観測性

業界がモノリシックなオンプレミス システムやアプリケーションからクラウドネイティブのマイクロサービスベースのアプリケーションに移行するにつれて、監視はかなり複雑化しています。その結果、可観測性への関心が高まりつつあります。可観測性の 3 つの柱はログ、トレース、メトリックであるとよく言われています。ログは、ほとんどのシステム コンポーネントとアプリケーションによって生成されて、システムまたはアプリケーションの機能に関する時系列データで構成されています。トレースは、アプリケーション内のロジックのフローを追跡します。メトリックは、CPU/RAM の予約または使用率、ディスク容量、ネットワーク接続などが含まれます。可観測性とは、これら 3 つの情報源すべてをまとめて利用することで、複雑なシステムの機能に関する発見と予測を行うことを意味します。これらの情報が利用できなければおそらく実現しません。可観測性の詳細はこちらをご覧ください。

​​​​​​​継続的なフィードバックの収集

継続的なフィードバックによって、チーム メンバーは仕事に必要なすべての情報をタイムリーに得られます。開発の観点から見ると、パイプラインに何らかの障害が生じたら、チームは直ちにアラートを受け取ります。また、開発者は、明確で詳細なコード テストの結果をできる限り速やかに利用できます。製品管理の観点では、チームは生産上の障害やパフォーマンス不足、報告されたバグを認識します。これまで、開発チームはスピードまたは品質の最適化しかできないと広く信じられてきました。継続的なフィードバックは、両方を可能にする DevOps の要素の 1 つです。

​​​​​​​文化を変える

DevOps にはコラボレーション、透明性、信頼、共感が必要です。これらの資質が既に備わっている稀な組織であれば、チームは DevOps プラクティスをかなり簡単に採用できます。そうではない場合は、これらの資質を育むためにいくらか努力が必要になります。最もよくある組織構造はサイロ化状態であり、チームごとに所有権と責任の領域が異なり、チーム間のコミュニケーションやコラボレーションは最小限です。DevOps が成功するためには、「構築した者が運用する」プラクティスを採用してこれらの障壁を排除する必要があります。これは、専門的な人やチームがいないという意味ではなく、単にチーム間のコミュニケーションとコラボレーションのルートがオープンで利用されているということです。チーム文化の構築に関する詳細についてご参照ください。

DevOps プラクティスは、今後も継続して磨かれていきます。DevOps の変革を開始して人とプロセスに重点を置き、高度なツール、統合、特長的な機能性を組み込んでチームを成熟させましょう。