DevOps

ソフトウェアコンサルタントのお気に入りのマントラは、どんな質問にも「依存する」と答える事です。 ソフトウェアコンサルタントがポジションを取らないのが好きだからではありません。 ソフトウェアに関する質問に対する真の答えは誰もいないからです。 絶対的な権利と間違いはなく、むしろ反対のバランスがあります。

たとえば、Web アプリケーションを開発する 2 つの主要な学校である、シングル ページ アプリケーション (SPA) とサーバー側アプリケーションの 2 つの主要な学校を取ります。 一方で、ユーザー エクスペリエンスは SPA の方が優れる傾向があり、Web サーバーへのトラフィック量を最小限に抑え、静的ホスティングのような単純なホストでホストできます。 一方、SPA の開発が遅くなり、テストが困難になる傾向があります。 どちらが適切な選択ですか? さて、それはあなたの状況によって異なります。

クラウドネイティブ アプリケーションは、同じ二分法に対して免疫を持っていません。 開発速度、安定性、スケーラビリティの点で明確な利点がありますが、管理が非常に困難になる可能性があります。

何年も前は、アプリケーションを開発から運用に移行するプロセスが 1 か月以上かかるのは珍しいことではありませんでした。 企業は、6 か月または毎年の周期でソフトウェアをリリースしました。 Windows 10 への継続的なアップデートが始まる以前のリリースの周期については、Microsoft Windows を見れば十分理解できます。 Windows XP と Vista の間で 5 年が経過し、Vista と Windows 7 の間でさらに 3 年が経過しました。

ソフトウェアを迅速にリリースできることは、急速に動く企業に、よりナマケモノのような競合他社よりも大きな市場優位性を与えるというかなりよく確立されています。 そのため、Windows 10 の主要な更新プログラムは約 6 か月ごとに更新されます。

より高速で信頼性の高いリリースを可能にしてビジネスに価値を提供するパターンとプラクティスは、総称して DevOps と呼ばれます。 これらは、アプリケーションの指定から、そのアプリケーションの提供と運用まで、ソフトウェア開発ライフサイクル全体にわたる幅広いアイデアで構成されています。

DevOps はマイクロサービスの前に出現し、DevOps を使用しないと、1 つだけでなく、運用環境の多くのアプリケーションのリリースと運用を容易にするために、より小さく、目的に合ったサービスへの移行が不可能になる可能性があります。

図 10-1 - DevOps とマイクロサービス。

優れた DevOps プラクティスを通じて、実際にアプリケーションを運用する作業の山の下で息をのむことなく、クラウドネイティブ アプリケーションの利点を実現できます。

DevOps に関しては、ゴールデン ハンマーはありません。 誰も高品質のアプリケーションをリリースして運用するための完全で包括的なソリューションを販売することはできません。 これは、各アプリケーションが他のすべてのアプリケーションと大きく異なるためです。 その一方で、DevOpsをより気軽なものにするツールがあります。 これらのツールの 1 つは Azure DevOps と呼ばれます。

Azure DevOps

Azure DevOps には長い血統があります。 その起源は、Team Foundation Server が最初にオンラインに移行し、その後、Visual Studio Online や Visual Studio Team Services というさまざまな名前変更を経てたどることができます。 しかし、長年にわたり、それは前任者よりもはるかに多くなっています。

Azure DevOps は、次の 5 つの主要なコンポーネントに分かれています。

図 10-2 - Azure DevOps。

Azure Repos - 従来の Team Foundation バージョン管理 (TFVC) と業界で人気のある Git をサポートするソース コード管理。 プル要求は、変更が行われるときのディスカッションを促進することで、ソーシャル コーディングを有効にする方法を提供します。

Azure Boards - ユーザーが最適に動作するワークフローを選択できるように努める問題と作業項目追跡ツールを提供します。 これは、開発のSCRUMとかんばんスタイルをサポートするものを含む事前に構成されたテンプレートの数が付属しています。

Azure Pipelines - Azure との緊密な統合をサポートするビルドおよびリリース管理システム。 ビルドは、Windows から Linux、macOS まで、さまざまなプラットフォームで実行できます。 ビルド エージェントは、クラウドまたはオンプレミスでプロビジョニングできます。

Azure Test Plans - テスト計画機能によって提供されるテスト管理と探索的テストのサポートによって、QA 担当者は取り残されません。

Azure Artifacts - 企業が独自の内部バージョンの NuGet、npm などを作成できるようにするアーティファクト フィード。 これは、一元化されたリポジトリの障害が発生した場合にアップストリーム パッケージのキャッシュとして機能する二重の目的を果たします。

Azure DevOps の最上位の組織単位は、プロジェクトと呼ばれます。 各プロジェクト内で、Azure Artifacts などのさまざまなコンポーネントのオンとオフを切り替えることができます。 これらの各コンポーネントは、クラウドネイティブ アプリケーションに対して異なる利点を提供します。 最も便利な 3 つの方法は、リポジトリ、ボード、パイプラインです。 ユーザーが GitHub などの別のリポジトリ スタックでソース コードを管理したいが、それでも Azure Pipelines やその他のコンポーネントを利用したい場合は、それは完全に可能です。

さいわい、開発チームにはリポジトリを選択する際に多くのオプションがあります。 そのうちの 1 つが GitHub です。

GitHub のアクション

2009 年に設立された GitHub は、プロジェクト、ドキュメント、コードをホストするための広く普及している Web ベースのリポジトリです。 Apple、Amazon、Google、メインストリーム企業など、多くの大企業が GitHub を使用しています。 GitHub では、Git という名前のオープン ソースの分散バージョン管理システムを基盤として使用します。 さらに、欠陥追跡、機能とプル要求、タスク管理、各コード ベースの Wiki など、独自の機能セットを追加します。

GitHub が進化するにつれて、DevOps 機能も追加されます。 たとえば、GitHub には、 GitHub Actionsと呼ばれる独自の継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインがあります。 GitHub Actions は、コミュニティを利用したワークフロー自動化ツールです。 これにより、DevOps チームは既存のツールと統合し、新製品を組み合わせ、既存の CI/CD パートナーを含むソフトウェア ライフサイクルにフックできます。

GitHub には 4,000 万人を超えるユーザーがいて、世界最大のソース コード ホストとなっています。 2018 年 10 月、Microsoft は GitHub を購入しました。 Microsoft は、GitHub は、開発者がプラグインして拡張できる オープン プラットフォーム であり続けることを約束しています。 独立企業として活動を続ける。 GitHub には、エンタープライズ アカウント、チーム アカウント、プロフェッショナル アカウント、無料アカウントのプランが用意されています。

ソース管理

クラウドネイティブ アプリケーションのコードを整理するのは困難な場合があります。 クラウドネイティブ アプリケーションは、単一の巨大なアプリケーションではなく、互いに通信する小規模なアプリケーションの Web で構成される傾向があります。 コンピューティングのすべてのことと同様に、コードの最適な配置は未解決の質問のままです。 さまざまな種類のレイアウトを使用する成功したアプリケーションの例がありますが、2 つのバリエーションが最も人気があるようです。

実際のソース管理自体に入る前に、適切なプロジェクトの数を決定する必要があります。 1 つのプロジェクト内には、複数のリポジトリとビルド パイプラインがサポートされています。 ボードはもう少し複雑ですが、1 つのプロジェクト内の複数のチームにタスクを簡単に割り当てることができます。 1 つの Azure DevOps プロジェクトから数百、数千人の開発者をサポートできます。 これは、すべての開発者が作業できる 1 つの場所を提供し、開発者が存在するプロジェクトがわからない場合に 1 つのアプリケーションを見つけるという混乱を軽減するため、最良のアプローチである可能性があります。

Azure DevOps プロジェクト内でマイクロサービスのコードを分割することは、少し難しい場合があります。

図 10-3 - 一つのリポジトリと多数のリポジトリ。

マイクロサービスごとのリポジトリ

一見すると、このアプローチは、マイクロサービスのソース コードを分割するための最も論理的なアプローチと思われます。 各リポジトリには、1 つのマイクロサービスを構築するために必要なコードを含めることができます。 このアプローチの利点は、すぐに確認できます。

1. アプリケーションのビルドと保守の手順は、各リポジトリのルートにある README ファイルに追加できます。 リポジトリを反転すると、これらの手順を簡単に見つけ、開発者のスピンアップ時間を短縮できます。
2. すべてのサービスは論理的な場所にあり、サービスの名前を知ることで簡単に見つけることができます。
3. ビルドは、所有するリポジトリに変更が加えられたときにのみトリガーされるように簡単に設定できます。
4. リポジトリに加わる変更の数は、プロジェクトに取り組んでいる少数の開発者に制限されます。
5. 開発者が読み取りと書き込みのアクセス許可を持つリポジトリを制限することで、セキュリティを簡単に設定できます。
6. リポジトリ レベルの設定は、所有チームが他のメンバーと最低限の話し合いで変更できます。

マイクロサービスの背後にある重要な考え方の 1 つは、サービスをサイロ化し、互いに分離する必要があるということです。 ドメイン 駆動設計を使用してサービスの境界を決定する場合、サービスはトランザクション境界として機能します。 データベースの更新は、複数のサービスにまたがるべきではありません。 この関連データのコレクションは、境界付きコンテキストと呼ばれます。 このアイデアは、サービスの残りの部分とは別の自律的なデータベースへのマイクロサービス データの分離によって反映されます。 このアイデアをソース コードに至る所まで伝達することは非常に理にかなっています。

ただし、この方法には問題はありません。 私たちの時代のよりぎくしゃくした開発の問題の1つは、依存関係の管理です。 平均 node_modules ディレクトリを構成するファイルの数を検討してください。 create-react-appのようなものを新しくインストールすると、何千ものパッケージが付属する可能性があります。 これらの依存関係を管理する方法の問題は難しい問題です。

依存関係が更新された場合、ダウンストリーム パッケージでもこの依存関係を更新する必要があります。 残念ながら、開発作業が必要なので、必ず、 node_modules ディレクトリは 1 つのパッケージの複数のバージョンで終わり、それぞれが少し異なる周期でバージョン管理されている他のパッケージの依存関係になります。 アプリケーションをデプロイするときは、どのバージョンの依存関係を使用する必要がありますか? 現在運用環境にあるバージョンは? 現在ベータ版ですが、コンシューマーが運用環境に移行する時点までに運用環境に存在する可能性が高いバージョン。 マイクロサービスを使用するだけでは解決されない困難な問題。

さまざまなプロジェクトに依存するライブラリがあります。 マイクロサービスを各リポジトリの 1 つに分割することで、内部リポジトリである Azure Artifacts を使用して内部依存関係を解決するのが最適です。 ライブラリ用のビルドでは、内部使用のために最新バージョンが Azure Artifacts にプッシュされます。 新しく更新されたパッケージへの依存関係を取得するには、ダウンストリーム プロジェクトを手動で更新する必要があります。

サービス間でコードを移動する場合、もう 1 つの欠点があります。 マイクロサービスへのアプリケーションの最初の分割が 100% 正しいと信じるのは良いでしょうが、サービス分割の間違いを犯さないほど優れているのはめったにありません。 したがって、機能とそれを駆動するコードは、サービスからサービスに移動する必要があります: リポジトリからリポジトリに。 あるリポジトリから別のリポジトリにジャンプすると、コードの履歴が失われます。 多くの場合(特に監査の場合)、コードの完全な履歴を持つことは非常に貴重です。

最終的かつ最も重要な欠点は、変更の調整です。 真のマイクロサービス アプリケーションでは、サービス間にデプロイの依存関係がないはずです。 疎結合があるため、サービス A、B、C を任意の順序でデプロイできる必要があります。 ただし、実際には、複数のリポジトリを同時にまたがる変更を行うのが望ましい場合があります。 たとえば、ライブラリを更新してセキュリティ ホールを閉じたり、すべてのサービスで使用される通信プロトコルを変更したりできます。

クロスリポジトリの変更を行うには、各リポジトリへのコミットを連続して行う必要があります。 各リポジトリの各変更は、プル要求とレビューを個別に行う必要があります。 このアクティビティの調整が困難な場合があります。

多くのリポジトリを使用する代わりに、すべてのソース コードを巨大な単一のリポジトリにまとめる方法があります。

単一リポジトリ

このアプローチでは、 monorepository とも呼ばれ、すべてのサービスのすべてのソース コードが同じリポジトリに配置されます。 最初は、このアプローチはソース コードを扱いにくくする恐ろしい考えのようです。 ただし、この方法で作業する利点は顕著です。

1 つ目の利点は、プロジェクト間の依存関係をより簡単に管理できる点です。 外部成果物フィードに依存する代わりに、プロジェクトは互いに直接インポートできます。 つまり、更新がすぐに行われ、競合するバージョンが開発者のワークステーションでコンパイル時に見つかる可能性が高くなります。 実際には、統合テストの一部を左にシフトします。

プロジェクト間でコードを移動するときに、ファイルが書き換えられるのではなく移動されたことが検出されるため、履歴を保持する方が簡単になりました。

もう 1 つの利点は、サービス境界を越える広範な変更を 1 回のコミットで行うことができるということです。 このアクティビティにより、個別に確認するために数十の変更を加える可能性があるオーバーヘッドが削減されます。

安全でないプログラミングプラクティスや API の問題のある使用を検出するために、コードの静的分析を実行できるツールは多数あります。 マルチリポジトリの世界では、各リポジトリを反復処理して問題を見つける必要があります。 1 つのリポジトリを使用すると、すべての分析を 1 か所で実行できます。

また、単一リポジトリアプローチには多くの欠点があります。 最も心配な点の 1 つは、単一のリポジトリを持つことでセキュリティ上の問題が発生するということです。 サービス モデルごとにリポジトリ内のリポジトリの内容がリークされた場合、失われるコードの量は最小限です。 1 つのリポジトリを使用すると、会社が所有するすべてのものが失われる可能性があります。 過去には多くの例があり、ゲーム開発の取り組み全体が脱線しています。 複数のリポジトリを使用すると、より少ない領域が公開されます。これは、ほとんどのセキュリティ プラクティスで望ましい特性です。

単一リポジトリのサイズは、急速に管理不能になる可能性があります。 これは、いくつかの興味深いパフォーマンスへの影響を示します。 もともと Windows チームの開発者のエクスペリエンスを向上させるために設計された 、Git 用の仮想ファイル システムなどの特殊なツールを使用することが必要になる場合があります。

1 つのリポジトリを使用するための引数は、Facebook または Google がソース コードの配置にこのメソッドを使用する引数に分けられます。 これらの企業にとって十分なアプローチであれば、それはすべての企業にとって正しいアプローチです。 問題の真実は、少数の企業がFacebookやGoogleの規模のようなものを運営しているということです。 これらのスケールで発生する問題は、ほとんどの開発者が直面する問題とは異なります。 鴨に良いことが雁にとって必ずしも良いとは限りません。

最終的には、どちらのソリューションもマイクロサービスのソース コードをホストするために使用できます。 ただし、ほとんどの場合、1 つのリポジトリで運用する場合の管理とエンジニアリングのオーバーヘッドは、大きな利点ではありません。 複数のリポジトリにコードを分割すると、懸念事項の分離が向上し、開発チーム間の自律性が促進されます。

標準ディレクトリ構造

1 つのリポジトリと複数のリポジトリに関係なく、各サービスには独自のディレクトリがあります。 開発者がプロジェクト間をすばやくクロスできるようにする最適な最適化の 1 つは、標準のディレクトリ構造を維持することです。

図 10-4 - 標準ディレクトリ構造。

新しいプロジェクトが作成されるたびに、適切な構造を配置するテンプレートを使用する必要があります。 このテンプレートには、スケルトン README ファイルや azure-pipelines.ymlなどの便利な項目を含めることもできます。 どのマイクロサービス アーキテクチャでも、プロジェクト間の分散度が高いため、サービスに対する一括操作がより困難になります。

複数のソース コード ディレクトリを含むディレクトリ全体にテンプレートを提供できるツールは多数あります。 Yeoman は JavaScript の世界で人気があり、GitHub は最近、同じ機能の多くを提供する リポジトリ テンプレートをリリースしました。

タスク管理

任意のプロジェクトでタスクを管理することは困難な場合があります。 開発者の生産性を最大限に高めるために設定するワークフローの種類については、前もって無数の質問に答える必要があります。

クラウドネイティブ アプリケーションは、従来のソフトウェア製品よりも小さいか、少なくとも小規模なサービスに分割される傾向があります。 これらのサービスに関連する問題やタスクの追跡は、他のソフトウェア プロジェクトと同じくらい重要です。 誰も作業項目の追跡を失ったり、問題が正しくログに記録されなかったことを顧客に説明したりすることを望んでいません。 ボードはプロジェクト レベルで構成されますが、各プロジェクト内で領域を定義できます。 これにより、複数のコンポーネント間で問題を分解できます。 アプリケーション全体のすべての作業を 1 か所に保持する利点は、作業項目をチーム間で簡単に移動できる点です。

Azure DevOps には、事前に構成された多数の一般的なテンプレートが付属しています。 最も基本的な構成では、知る必要があるのがバックログの内容、ユーザーの作業内容、実行内容です。 作業を優先して完了したタスクを顧客に報告できるように、ソフトウェアの構築プロセスをこの可視性で把握することが重要です。 もちろん、 to do、 doing、 doneなどの単純なプロセスに関するソフトウェア プロジェクトはほとんどありません。 ユーザーがプロセスに QA や Detailed Specification などの手順を追加し始めるのに時間はかかりません。

アジャイル手法の最も重要な部分の 1 つは、定期的な自己紹介です。 これらのレビューは、チームが直面している問題とその改善方法に関する分析情報を提供するためのものです。 これは、多くの場合、開発プロセスを通じて問題と機能のフローを変更することです。 そのため、追加のステージでボードのレイアウトを拡張することは完全に正常です。

ボード内のステージは、組織のツールだけではありません。 ボードの構成によっては、作業項目の階層があります。 ボードに表示できる最も細かい項目はタスクです。 既定では、タスクには、タイトル、説明、優先度、残存作業時間の見積もり、他の作業項目または開発項目 (ブランチ、コミット、プル要求、ビルドなど) にリンクする機能のフィールドが含まれています。 作業項目は、アプリケーションのさまざまな領域とさまざまなイテレーション (スプリント) に分類して、見つけやすくすることができます。

図 10-5 - Azure DevOps のタスク。

説明フィールドは、期待される通常のスタイル (太字、斜体、取り消し線) と画像を挿入する機能をサポートしています。 これにより、作業やバグを指定するときに使用するための強力なツールになります。

タスクは、より大きな作業単位を定義する機能にロールアップできます。 次に、機能を エピックにロールアップできます。 この階層内のタスクを分類すると、大規模な機能がロールアウトにどれだけ近いかを理解しやすくなります。

図 10-6 - Azure DevOps の作業項目。

Azure Boards には、問題のさまざまな種類のビューがあります。 まだスケジュールされていない項目は、バックログに表示されます。 そこから、スプリントに割り当てることができます。 スプリントは、ある程度の作業が完了することが予想されるタイム ボックスです。 この作業には、タスクだけでなく、チケットの解決も含めることができます。 その後、スプリントボードセクションからスプリント全体を管理できます。 このビューは、作業の進行状況を示し、スプリントが成功したかどうかを常に更新する見積もりを提供するバーンダウン チャートが含まれています。

図 10-7 - Azure DevOps のボード。

現時点では、Azure DevOps の Boards に大きな力があることは明らかです。 開発者にとっては、何が作業されているかを簡単に確認できます。 プロジェクト マネージャーの場合は、今後の作業に関するビューと、既存の作業の概要が表示されます。 マネージャーには、リソースと容量に関するレポートが多数あります。 残念ながら、作業を追跡する必要のないクラウドネイティブ アプリケーションに関する魔法は何もありません。 ただし、作業を追跡する必要がある場合は、Azure DevOps よりもエクスペリエンスが優れている場所がいくつかあります。

CI/CD パイプライン

ソフトウェア開発ライフサイクルの変化の中で、継続的インテグレーション(CI)と継続的デリバリー(CD)の登場ほど革命的なものはほとんどありませんでした。 変更がチェックインされるとすぐに、プロジェクトのソース コードに対して自動テストをビルドして実行すると、早い段階で間違いがキャッチされます。 継続的インテグレーション ビルドが登場する前は、リポジトリからコードをプルして、テストに合格しなかったり、ビルドできなかったりすることも珍しくありません。 その結果、破損の原因を追跡しました。

従来、運用環境にソフトウェアを出荷するには、広範なドキュメントと手順の一覧が必要です。 これらの各手順は、非常にエラーが発生しやすいプロセスで手動で完了する必要があります。

図 10-8 - チェックリスト。

継続的インテグレーションの姉妹は、新しく構築されたパッケージを環境にデプロイする継続的デリバリーです。 手動プロセスは開発速度に合わせてスケーリングできないため、自動化がより重要になります。 チェックリストは、どの人間よりも速く正確に同じタスクを実行できるスクリプトに置き換えられます。

継続的デリバリーが提供される環境は、テスト環境であるか、多くの主要なテクノロジ企業によって行われているように、運用環境である可能性があります。 後者では、変更がユーザーの運用環境を損なわないという確信を与えることができる高品質のテストへの投資が必要です。 継続的インテグレーションがコードの早期継続的デリバリーで問題をキャッチしたのと同じ方法で、デプロイ プロセスの問題を早期にキャッチします。

ビルドと配信プロセスを自動化することの重要性は、クラウドネイティブ アプリケーションによって強調されています。 デプロイがより頻繁に、かつより多くの環境に対して行われるため、手動でのデプロイはほとんど不可能になりつつあります。

Azure ビルド

Azure DevOps には、継続的インテグレーションとデプロイをこれまで以上に簡単にするための一連のツールが用意されています。 これらのツールは、Azure Pipelines の下にあります。 1 つ目は Azure ビルドです。これは、YAML ベースのビルド定義を大規模に実行するためのツールです。 ユーザーは、独自のビルド マシンを持ち込むか (ビルドに細心の注意を払って環境を設定する必要がある場合に適しています)、または Azure でホストされる仮想マシンの絶えず更新されたプールからマシンを使用できます。 これらのホスト型ビルド エージェントには、.NET 開発だけでなく、Java から Python、iPhone 開発まで、さまざまな開発ツールがプレインストールされています。

DevOps には、任意のビルド用にカスタマイズできる、さまざまなすぐに使用できるビルド定義が含まれています。 ビルド定義は、ソース コードと共にバージョン管理できるように、 azure-pipelines.yml と呼ばれるファイルで定義され、リポジトリにチェックインされます。 これにより、そのブランチだけに変更をチェックインできるため、ブランチ内のビルド パイプラインに変更を加えるのがはるかに簡単になります。 完全なフレームワークで ASP.NET Web アプリケーションを構築するための azure-pipelines.yml の例を図 10-9 に示します。

name: $(rev:r)

variables:
  version: 9.2.0.$(Build.BuildNumber)
  solution: Portals.sln
  artifactName: drop
  buildPlatform: any cpu
  buildConfiguration: release

pool:
  name: Hosted VisualStudio
  demands:
  - msbuild
  - visualstudio
  - vstest

steps:
- task: NuGetToolInstaller@0
  displayName: 'Use NuGet 4.4.1'
  inputs:
    versionSpec: 4.4.1

- task: NuGetCommand@2
  displayName: 'NuGet restore'
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  displayName: 'Build solution'
  inputs:
    solution: '$(solution)'
    msbuildArgs: '-p:DeployOnBuild=true -p:WebPublishMethod=Package -p:PackageAsSingleFile=true -p:SkipInvalidConfigurations=true -p:PackageLocation="$(build.artifactstagingdirectory)\\"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  displayName: 'Test Assemblies'
  inputs:
    testAssemblyVer2: |
     **\$(buildConfiguration)\**\*test*.dll
     !**\obj\**
     !**\*testadapter.dll
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: CopyFiles@2
  displayName: 'Copy UI Test Files to: $(build.artifactstagingdirectory)'
  inputs:
    SourceFolder: UITests
    TargetFolder: '$(build.artifactstagingdirectory)/uitests'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact'
  inputs:
    PathtoPublish: '$(build.artifactstagingdirectory)'
    ArtifactName: '$(artifactName)'
  condition: succeededOrFailed()

図 10-9 - サンプル azure-pipelines.yml

このビルド定義では、多数の組み込みタスクを使用して、ビルドの作成を、レゴ セットの構築と同じくらい簡単にします (巨大なミレニアム ファルコンよりも簡単)。 たとえば、NuGet タスクは NuGet パッケージを復元し、VSBuild タスクは Visual Studio ビルド ツールを呼び出して実際のコンパイルを実行します。 Azure DevOps には何百もの異なるタスクが用意されており、コミュニティによって何千ものタスクが管理されています。 実行しようとしているビルド タスクに関係なく、誰かが既にビルドしている可能性があります。

ビルドは、手動、チェックイン、スケジュール、または別のビルドの完了によってトリガーできます。 ほとんどのケースでは、チェックインのたびにビルドすることをお勧めします。 ビルドをフィルター処理して、リポジトリのさまざまな部分または異なるブランチに対して異なるビルドを実行できます。 これにより、プル要求でテストを減らして高速ビルドを実行したり、トランクに対して夜間に完全な回帰スイートを実行したりするシナリオが可能になります。

ビルドの最終的な結果は、ビルド 成果物と呼ばれるファイルのコレクションです。 これらの成果物は、ビルド プロセスの次のステップに渡すことも、Azure Artifacts フィードに追加して、他のビルドで使用することもできます。

Azure DevOps リリース

ビルドではソフトウェアを出荷可能パッケージにコンパイルしますが、継続的デリバリーを完了するには、成果物をテスト環境にプッシュする必要があります。 このために、Azure DevOps はリリースと呼ばれる別のツールを使用します。 リリース ツールでは、ビルドで使用できるのと同じタスクライブラリを使用しますが、"ステージ" という概念が導入されています。 ステージは、パッケージがインストールされる分離環境です。 たとえば、製品が開発、QA、運用環境を利用する場合があります。 コードは、それに対して自動テストを実行できる開発環境に継続的に配信されます。 これらのテストに合格すると、リリースは手動テストのために QA 環境に移動します。 最後に、コードは運用環境にプッシュされ、すべてのユーザーに表示されます。

図 10-10 - リリース パイプライン

ビルド内の各ステージは、前のフェーズの完了によって自動的にトリガーできます。 ただし、多くの場合、これは望ましくありません。 コードを運用環境に移行するには、誰かからの承認が必要になる場合があります。 リリース ツールは、リリース パイプラインの各ステップで承認者を許可することで、これをサポートします。 特定のユーザーまたはユーザーのグループが運用環境に移行する前にリリースでサインオフする必要があるルールを設定できます。 これらのゲートにより、手動の品質チェックが可能になり、生産に入るものを制御するために関連する規制要件に準拠することもできます。

だれでもビルド パイプラインを取得

多くのビルド パイプラインを構成するコストは発生しないため、マイクロサービスごとに少なくとも 1 つのビルド パイプラインを用意すると便利です。 理想的には、マイクロサービスは任意の環境に個別にデプロイできるため、関連付けられていない大量のコードを解放することなく、それぞれが独自のパイプラインを介して解放できることは完璧です。 各パイプラインには独自の承認セットを設定できます。これにより、各サービスのビルド プロセスのバリエーションが可能になります。

バージョン管理されたリリース

リリース機能を使用する欠点の 1 つは、チェックインした azure-pipelines.yml ファイルで定義できないことです。 ブランチごとのリリース定義を持つことから、プロジェクト テンプレートにリリース スケルトンを含めるまで、多くの理由が考えられます。 幸い、いくつかのステージのサポートをビルド コンポーネントに移行する作業が進行中です。 これはマルチステージ ビルドと呼ばれ、 最初のバージョンが利用可能になりました。