DevOpsの方法論。 成功のための原則｜StackPulse

DevOpsの方法論は、ソフトウェア開発と情報技術（IT）運用という2つの分野を統合しています。 DevOps 手法の主な目標は、自動化、コミュニケーション、および継続的なワークフローを使用することによって達成される、迅速な製品リリースです。 DevOps チームは、DevOps プロセスを作成する際にこれらの原則を適用します。このプロセスには通常、計画、コード、構築、テスト、配信、配備、および監視の 7 段階があります。

• DevOps の手法とは何ですか
• DevOps 6 コア原則
• DevOps プロセスとは何ですか
  • DevOps プロセスとは何か
    DevOps の手法とは、計画、構築、テスト、配備、監視の 7 段階があります。
  • DevOps vs Agile: a comparison

  What Is the DevOps Methodology?

  DevOps methodology is a set of practices that requires the collaboration of development and operations teams throughout the software development lifecycle (SDLC). アジャイルプラクティスを取り入れ、チームのサイロを破壊し、手動タスクを自動化し、継続的なフィードバックによって生産性を向上させることに重点を置いています。

  DevOpsチームを使用する場合、組織は多くの場合、いくつかのプラクティスやツールを同時に実装します。 これには、

  • 継続的インテグレーション/継続的デプロイメント (CI/CD) – ソフトウェア開発ライフサイクルの効率、品質、および速度を改善するために、自動化を活用する一連のプロセス。 CI は、できるだけ早くテストおよび統合されるコードベースへの頻繁で小さな修正を含みます。 CDは、手動でのアップデートやパッチを必要とせずに、新しいコードを頻繁に本番環境にリリースすることである。 多くの場合、これらのツールチェーンはクラウドでホストされるサービスおよびリソースで構成され、クラウドネイティブな開発と分散チームのより大きなサポートを可能にします。
  • マイクロサービス – クラウドネイティブなアプリケーションで使用されるアーキテクチャで、より大きなスケーラビリティ、可用性、および柔軟性を可能にします。
  • Infrastructure as code (IaaC) – チームがソフトウェアおよびコード化された定義ファイルを通じて、インフラのプロビジョニング、構成、および管理を行うための方法。

  The Core DevOps Principles

  DevOps 方法論を作成し、その下で運用する場合、採用を検討すべきいくつかの基本原則が存在します。

  クロストレーニング

  DevOpsでは、SDLCのすべてのプロセスについてチームメンバーをクロストレーニングするための努力がなされています。 これは、すべてのチームメンバーが同じように熟練していなければならないということではありませんが、全員が使用されるプロセス、ツール、およびスキルに精通している必要があります。

  このようにチームメンバーの知識が重なり合うと、チームメンバー間のコミュニケーションが容易になる。 また、物事がどのように行われるべきかという期待にメンバーが「囚われる」ことが少なくなるため、斬新な解決策を促進することができる。 また、クロストレーニングは、他者への依存によるボトルネックを防ぎ、生産性を向上させることができる。

  Collaboration

  Collaboration とそれに必要なコミュニケーションは、DevOps の主要な要素です。 この方法論は、チーム・メンバーがスムーズに協力し、何かが期待通りに動作していないときにフィードバックに対応することに依存しています。 チーム・メンバーがコラボレーションできない場合、作業はサイロ化し、ステージの完了によって生産性が制限されます。

  継続的改善

  DevOpsでは、小さな変更を繰り返し、変更が検査しきい値に合格するまで改良していくプロセスを使用します。 変更が受け入れられるとすぐに、次の変更が開始されます。 この継続的な改善は、製品開発、パイプラインのパフォーマンス、およびプロセス効率など、DevOpsのすべての側面に適用されます。

  アカウンタビリティ

  DevOps モデルでは、開発タスクであれ運用タスクであれ、すべてのタスクに対するアカウンタビリティが求められ、どちらも組織のすべてのメンバーによって平等に所有されるべきです。 これは、「他人の問題」という従来の考え方を排除し、開発または運用に関連するかどうかにかかわらず、チームの行動を慎重にすることを保証するのに役立ちます。 また、メンバー全員が同等の努力と責任を期待するため、チーム内の関係を構築し、強固なものにすることができます。

  透明性

  プロセス、構成、ツール、および期待値の透明性は、すべてDevOpsにおいて重要です。 透明性がなければ、チームは効果的にコラボレーションすることができず、「我々 vs 彼ら」という感情が残ります。 このため、コミュニケーションが妨げられ、他の人に責任を負わせることが難しくなります。 透明性があれば、すべてのチームメンバーが発生した問題の特定に協力し、全体像の中で改善策を提案することができます。

  Automation

  DevOps 自動化は、チームが作業を合理化および標準化するのを支援します。 また、手順を定義し、文書化する必要があるため、透明性の創出にも役立ちます。 退屈なタスクや時間のかかるタスクを自動化することで、DevOps チームはより高度な作業に集中することができます。 この集中により、品質が向上し、イノベーションが促進されます。

  DevOpsプロセス

  DevOpsプロセス内の個々の手順は異なる場合がありますが、全体のプロセスはかなり均一な手順の集合に従います。 これらのステップはサイクルで発生し、フィードバック ループに応じて変更されたり、前のステップにループバックしたりすることがあります。 DevOpsのライフサイクルには、通常、次のステップが含まれます。

  • 計画-プロジェクト、スプリント/反復、または1日の始まりに、作業が計画され、優先順位が付けられます。 これは、すべてのチームメンバーが現在の目標を理解し、どのような作業が期待されるかを定義するのに役立つ。
  • コード開発者は、現在の反復のために定義されたタスクを満たすコードの変更または追加を作成し、提出します。 これらは、すべての開発者がアクセス可能なマスターコードベースに基づいている。 このステップには、コードレビューと、必要な説明や調整も含まれる。 提出されたコードがテストに合格しなかった場合、修正のためにこのステップに戻されます。
  • ビルド-提出されたコードは、コンパイル、ユニットテスト、およびパッケージ化されます。 これは一般に、CI/CD パイプラインの最初の自動化されたステップです。 ビルドが失敗すると、開発者にフィードバックが送られ、提出された変更は拒否されます。 ビルドが成功した場合は、追加のテストに回されます。
  • テスト-成功したビルドは、機能性、品質、および多くの場合セキュリティを保証するための一連のテストに渡されます。 理想的には、最も速い、または最も重要なテストが最初に実行されます。 この方法では、テストが失敗した場合、元のコード変更にできるだけ早くフィードバックを返すことができ、労力が無駄になりません。 すべてのテストに合格したら、ビルドはデリバリーに渡され、変更はマスターコードブランチにマージされます。 これにより、すべての開発者が同じベースから作業を継続できるようになります。
  • デリバー-最後にパスしたビルドが維持され、デプロイのために保持されます。
  • 配備-ビルドは、ユーザー受け入れなどの追加テストのためにテスト環境に配備されることがある。 または、リリースのためにステージング環境またはプロダクション環境に配信することができる。
  • 監視-リリース後、バージョンを監視して、見逃していた問題を特定し、将来の改良に適用できる使用データを収集します。 DevOps モニタリングについては、こちらの記事で詳しく説明しています。 DevOpsモニタリング。

  DevOps vs. Agile: What’s the Difference and How Are They Related?

  DevOps 方法論について話すとき、それはしばしばアジャイルと関連付けられます。 多くの DevOps チームがアジャイル プラクティスを採用していることを考えると、これは理にかなっています。 また、両方の方法論は、スピード、効率、および品質を向上させることに重点を置いています。 にもかかわらず、方法論は異なっており、一方が他方を必ずしも必要とするわけではありません。

  コミュニケーション

  アジャイル手法では、チーム間のコミュニケーションとプロジェクト プロセス全体への顧客の参加に焦点が当てられています。 同様に、アジャイルプロセスにおけるほとんどのフィードバックは顧客から来る。

  DevOpsでは、コミュニケーションは開発者とオペレーションが中心である。 顧客からのフィードバックは、計画段階と納品段階で役割を果たしますが、中間段階では一般的に存在しません。

  チーム構造

  アジャイルとDevOpsの両方が、スキルの共有とクロストレーニングを優先している。 しかし、DevOpsはこれらのスキルを責任よりもコミュニケーションとコラボレーションに適用する傾向がある。 DevOpsチームでは、開発者はコード作成を担当し、テストと運用チーム（DevOpsチームと呼ばれる）はパイプライン管理、環境設定、デプロイメントを担当します。

  これに対して、アジャイルチームは責任の境界線を曖昧にすることがよくあります。 アジャイルチーム内では、誰もが必要なタスクは何でも引き受けることが奨励され、役割の分離はあまり行われない。 この結果、アジャイルは小規模なチームでうまく機能する傾向があり、一方、デブオプスは大規模なチームに必要な構造を提供するのに適しています。

  タイムスケジュール

  アジャイル手法は、スプリントまたは時間制限のあるイテレーションに従います。 プロジェクトが完了するまで、複数のスプリントが実行され、それぞれで特定のタスクと目標が定義されます。 スプリントと期待される作業は、しばしばチームの成果に合わせて調整されます。

  DevOpsの実装では、目標は常に成果物を持つことです。 しかし、チームはスプリントまたはイテレーションを使用して、特定のリリースに入ることが期待される作業を定義することがあります。 さらに、DevOps チームはより具体的な納期とベンチマークに拘束されることが多く、製品がいつ完了するかを定義する柔軟性はあまりありません。 StackPulseによる継続的な運用、監視、およびフィードバック

  ビジネスのデジタル化が進むにつれ、それらを強化するソフトウェア サービスの信頼性がビジネスクリティカルな問題になっています。 すべてのソフトウェア システムは、どんなによく設計されていても、プロダクション アラートが発生します。 これらは、エンド ユーザーにほとんど影響を与えないローカルな問題か、ユーザーへのサービスの可用性に影響を与える重要な問題のいずれかです。

  どちらの場合も、関連する所有者が問題を調査、分析し、必要であれば修正することが必要です。

  • R&D および DevOps チームの生産性への悪影響
  • オーナーとサポートチームの「アラート疲労」
  • 本番サービスのダウンタイムの長期化

  StackPulse は DevOps サイクルの運用、監視、フィードバック段階用の自動化プラットフォームです。 DevOpsチームとエンジニアリングチームは、これらのプロセスのための成文化されたプレイブックを定義することができます。 これにより、組織は、再現可能かつ測定可能な方法でプロセスを自動化し、手作業を増やすことなく、必要な頻度でそれらをトリガーすることができます。