Azure DevOps Online Vol.3 - Inside Azure Pipelines
•
6 likes•978 views
It documents describe into Azure Pipelines. How to create pipeline with YAML file. It does difference between YAML and Classic Editor.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Azure DevOps Online Vol.3 - Inside Azure Pipelines
Similar to Azure DevOps Online Vol.3 - Inside Azure Pipelines (20)
More from Kazushi Kamegawa
More from Kazushi Kamegawa (20)
Azure DevOps Online Vol.3 - Inside Azure Pipelines
- 1. Azure DevOpsオンライン Vol.3 Azure Pipelines かめがわ かずし（@kkamegawa）
- 2. 自己紹介 personal: name: かめがわ かずし alias: kkamegawa community: MVP: Microsoft MVP for Developer Technologies(2009-) UsersGroup: Team Foundation Server Users Group URL: https://dev.azure.com/tfsug/tfsuginfo Blog: はてなブログ URL: https://kkamegawa.hatenablog.jp
- 3. This contents based on 2020/9/22
- 5. お品書き Azure Pipelinesについて 登場、Azure DevOps Server 2020
- 6. Azure Pipelines 対応レポジトリ(Azure以外も)にあるファイルをビルド、デプ ロイするサービス。 自前で管理(Self-hosted) 1+Visual Studio Enterpriseのライセンス分並列 Azure DCで提供(Microsoft-hosted) プライベートrepoでは1800分/月が無償。超えると有償 OSSでは10並列まで無償。 プライベートrepoで並列度あげる場合は有償 インフラはGitHub Actions / VS App Centerと共通
- 7. Azure Pipelines vs GitHub Actions Azure Pipelines GitHub Actions 形式 YAML / Classic GUI YAML 課金 OSS : 10並列。無制限 プライベート : プランによる OSS : 10並列。無制限 プライベート : プランによる コミュニティフロー marketplaceでタスク単位提供 Marketplaceでの提供（多い） 指定したエージェントに入れる Capabilities(環境変数か明示) Label コマンドシェル Windowsではcmd.exe WindowsではPowerShell (shell: cmdを指定すれば cmd.exe) Multi-Stage Pipeline 一つのYAML 明示的に分割 https://docs.github.com/en/actions/learn-github- actions/migrating-from-azure-pipelines-to-github-actions ※:他にもAzure DevOpsにしかない機能(Environmentsなど)がある
- 8. Azure Pipelinesが提供する環境 OS version Latest Windows • Windows Server 2016-VS2017 • Windows Server 2019-VS2019 Windows Server 2019- VS2019 macOS • 10.14 • 10.15 10.15 Linux • 16.04 • 18.04 • 20.04 18.04 (20.04はプレビュー) 参考:Microsoft-hosted agent TIPS： .NET CoreやJavaScriptベースといったクロスプラットフォームであればmacOSのエージェントを指定するのがおすすめ。 実機で動いていると思われ、ディスク性能などがかなり違う
- 11. レポジトリの監視・取得 多様なレポジトリをサポート(Git / Subversion / TFVC) Azure Repos / GitHub (Enterprise Server) / BitBucket(Server/Cloud) 複数レポジトリからの同時チェックアウト(マルチチェック アウト)も可能 Gitベースとそれ以外ではサポート機能に若干差異 YAMLのサポート有無でも差異あり
- 12. マルチチェックアウトの定義 対象の外部レポジトリを resourcesに登録 複数のレポジトリ(異なる サービスでもOK)からgit cloneする 参考:Check out multiple repositories in your pipeline resources: repositories: - repository: MyGitHubRepo type: github endpoint: MyGitHubServiceConnection name: MyGitHubOrgOrUser/MyGitHubRepo - repository: MyAzureReposGitRepository endpoint: MyAzureReposGitServiceConnection type: git name: OtherProject/MyAzureReposGitRepo steps: - checkout: self - checkout: MyGitHubRepo - checkout: MyAzureReposGitRepository 自動checkoutなし 外部からcheckout service connection endpoint GitHub/Azure Repos/Bitbucket
- 14. ソースに対する手続きを記述 - YAML vs Classic 2018/9(Azure DevOpsへの改名)のタイミングで登場 YAMLのMulti-Stageも一般公開になって、準備が整って います GUIのClassic Editorは今後強化されない予定 TFVCを使う場合はGUIでもOK YAMLサポートしない機能があるため
- 15. Classic vs YAML
- 16. YAMLとClassicの機能比較 YAML Classic Work Itemとの関連付け ✔（コミット時指定、ブランチ指定） キャッシュ指定 ✔ コンテナージョブ ✔ Deployment group Job Environmentで代替 ✔ リリースゲート Environmentで一部代替 ✔ Service Container ✔ Task Groups Templateで代替 ✔ PR Tigger ✔ Releaseのみ Stage ✔ Releaseのみ Automated Tests ✔ • 管理が分散しておすすめはしないが、YAML Build + Classic Releaseという組 み合わせも考えられる 参考：Use Azure Pipelines
- 17. Stage to Run Automated Test Test Plansの”Stage to run automated tests”は YAMLのマルチステー ジを認識しない（現状 の制限？） 使う場合はClassic Build/Releaseが必要
- 19. YAMLの構造 trigger: - master pool: vmImage: 'ubuntu-latest’ variables: buildConfiguration: 'Release' SolutionFiles: '**/*.sln’ Resources: repositories: - repository: templates type: git name: SessionDemo/Pipelines stages: - stage: Build displayName: 'Build Solution' jobs: - job: Build pool: vmImage: 'Windows-latest' demands: - msbuild - visualstudio steps: - task: UseDotNet@2 displayName: 'Install 3.x .NET Core' inputs: packageType: 'sdk' version: '3.x' - task: NuGetToolInstaller@1 inputs: versionSpec: '5.x' checkLatest: true - task: DotNetCoreCLI@2 displayName: 'Restore Nuget Package' inputs: command: 'restore' projects: '$(SolutionFiles)' feedsToUse: 'select'
- 20. YAMLの構造 セクション 代表的なキーワード 役割 Pipeline Trigger Resources Environments ビルドトリガー 参照リソース（外部） ビルド関連の情報を管理 Stages Stage Jobs ビルド・リリースを管理(なくてもよい) ビルド・リリースを実行する範囲 Jobs Job Steps Services Strategy ビルド・リリースを実行する範囲 具体的な処理を記載 接続するサービスを記載 ジョブを実行するための方式を定義 Steps Task ビルドやリリースの具体的な処理手順 Deployment Strategy Jobs ジョブを実行するための方式を定義 ビルド・リリースを実行する範囲 共通 Pool Variables Condition ビルドを実行する環境を指定 変数定義 ビルド実行する条件を指定
- 21. 最小限のYAML .NET Coreのビルドのみ trigger/pool/variablesを定義 job配下に実行するコマンド タスクを列挙 trigger: - master pool: vmImage: 'ubuntu-latest' variables: buildConfiguration: 'Release' solutionFiles: '**/*.sln' jobs: - job: Build steps: - task: NuGetCommand@2 inputs: command: 'restore' restoreSolution: '**/*.sln' feedsToUse: 'select' - task: DotNetCoreCLI@2 inputs: command: 'build' projects: '$(solutionFiles)'
- 22. YAMLの育て方 1. Try & Error 2. 少なくともJobsの単位で動くようになってから次 のJobsやStageへ移行 3. 長くなりすぎたらTemplateへ切り出し。 4. 1へ戻る
- 23. Azure Pipelinesが動くタイミング 手動 YAMLのtrigger指定に一致したとき GUIで設定されたtrigger指定に一致したとき Azure CLI / REST APIで呼び出し
- 24. pull request含めたtriggerの挙動 トリガー 挙動 trigger: none パイプラインの実行が手動のみ。 trigger: - master - dev master / devブランチに対して変更があった場合、パイプラインが実行される。 ただし、この二つのブランチに対してpull requestがあった場合もパイプラインが 呼び出される。 pr: none masterにコミットされた場合は実行してほしいけど、pull requestではパイプライ ンが動いてほしくない場合に指定。 pr: master 同じ設定だが、masterにpull requestがあった場合はパイプラインを実行する場合 に指定。 trigger: branches: include: - master: paths: include: - src/* exclude: - azure-pipelines.yml masterブランチのsrc配下のパスに何かのファイルがコミットされた場合、パイプ ラインを実行する。 azure-pipelines.ymlが変更されてもビルドは実行されない。
- 25. pull requestのときだけビルドしたい #YAMLのトリガーは無効 trigger: none Pull Requestでビルド開始
- 27. 複数の構成を一度にビルドする 複数プラットフォーム/構成のビ ルドしたい場合に使用する strategy/matrixを指定すると対 象のvariablesに対して一度にビ ルドできる 並列数も指定可能 pool: vmImage: 'Windows-latest' strategy: matrix: x64: BuildPlatform: 'x64' x86: BuildPlatform: 'x86' AnyCPU: BuildPlatform: 'Any CPU' variables: buildConfiguration: 'Release' solutionFiles: '**/*.sln' jobs: - job: Build steps: - task: VSBuild@1 inputs: solution: '$(solution)' platform: '$(BuildPlatform)' configuration: '$(BuildConfiguration)'
- 28. デプロイ戦略の違い ビルド→本番デプロイというケースは多くない RunOnece/ Rolling / Canaryというデプロイ戦略をサポート ビルド 検証 本番 P1 P2 P3 P4 P1 P2 P3 P4 ビルド ビルド 検証 検証 P1～P4：本番用インスタンス RunOnece Rolling Canary 数%ずつトラフィック見て展開順番に展開
- 29. 機密情報の扱い方 Libraryに格納(パスワード、各種証明書等) さらに機密性の高いものはAzure Key Vaultに格納 オンプレミスのAzure DevOpsでもSQL Server内で暗 号化されています。
- 31. いつでもリリースされたくない - Environments Environmentsにリソース定義 必要なチェックを指定する 展開する前/後の状態確認 勤務時間内か 承認があるか 外部のREST APIの結果が問題ないか …等
- 32. Agent Poolの仕組み
- 33. Azure DevOpsでのPipelineエージェントプール Pipelines Agent Pool Default Hosted Microsoft Hosted 1 2 3 Visual Studio 2017 / 2019 macOS 10.15 / Ubuntu 16/18/20 Self Hosted 1 2 3 オンプレミスエージェント Target Servers 1 2 3 デプロイ先
- 34. Pipelinesのエージェントが配置可能な構成 • オンプレミス、クラウドにエージェントの配置 が可能 • Firewall/proxyの背後でも443/tcpだけ通って いれば問題ない • 宛先のアドレスまで絞る場合は以下を参照 Allowed address lists and network connections • Proxy経由する場合は以下を参照 Run a self-hosted agent behind a web proxy
- 35. どうしてもビルドがうまくいかない… よくある…以下のタスクは特にはまりやすい copy files download xx upload xx シェル系 publish xx エージェントのどの場所で動いているか、成果物が 生成された場所を理解してないと時間を溶かす
- 36. エージェント内のフォルダー構成 ｛agent_work｝¥{index}¥a ｛agent_work｝¥{index}¥s ｛agent_work｝¥{index}¥TestResults ｛agent_work｝¥r{index}¥a ｛agent_work｝¥{index}¥b 値 意味 Build.ArtifactStagingDir ectory Build.StagingDirectory 成果物をコピー する前のフォル ダー Build.SourcesDirectory System.DefaultWorking Directory ソースファイル がダウンロード されるフォル ダー Build.BinariesDirectory コンパイルされ たバイナリー用 フォルダー Agent.ReleaseDirectory Classic用リリース フォルダー Common.TestResultsDir ectory テスト結果格納 用
- 38. どっち使う？ Microsoft-hosted Self-hosted CI環境のメンテナンスしたくない ✔ クラウドサービスへ展開したい ✔ 上限なく並列度を上げたい（※） ✔ 巨大(10GB超)なファイルを使いたい ✔ 多コアで高速ビルドしたい ✔ 古い/ベータ版環境を使いたい ✔ オンプレミスにデプロイしたい ✔ クラウド対応していないソフトがあ る（ライセンス等) ✔ ※：ただし、並列数分のエージェントの購入が必須
- 39. Microsoft-HostedとSelf-Hostedの中間 - scale set agents 高速な環境で大きなファイルを使いたいけど、オン プレミスに用意できないような場合にどうぞ 参考：Azure Virtual Machine scale set agents
- 40. よくある質問 もっと高性能なMicrosoft-Hosted提供されない？ 残念ながら今のところ… Scale set agentを使ってください。 AzureにデプロイするときPublic IP使わないとダメ？ 12月にService Tagがサポートされることになったので、そ れまで待つか、Scale set agentを使ってください Self-hostedに何が入ってるの？ GitHubにMicrosoft-Hostedのイメージ作るためのスクリプト が公開されているので、こちらをみてください。 イメージはいつ更新されるの？ 基本毎週更新しているそうです。 古くなったOSのイメージは毎月更新になります。 イントラの中でも大丈夫？ 443/tcpといくつかのアドレスが通っていれば大丈夫 どうしてもYAML使わないとダメ？ MSの伝統で”Classic”とつくと投資が悪化するので、早めの 移行でフィードバックしましょう。 ArtifactとAzure Artifactsって何が違う？ ビルドの生成物がArtifact パッケージ管理と生成物を管理するサービスがAzure Artifactsです。 YAMLとClassicで機能差ないの？ 割となくなってきたはずです。回避方法があるものも多い です。
- 41. (参考)パイプライン実行時セキュリティ調査 成果物に対してOSSの脆弱性監査を実施する WhiteSource Bolt Black Duck Secure DevOps Kit for Azureのようなツールでスキャ ンする