概要
Azure DevOpsを業務で使いそうなので下記のUdemy講座を受講してみた。
重要そうなところをメモしておく。
Learn DevOps: Docker, Kubernetes, Terraform and Azure DevOps
DockerやTerraformはなんとなくわかっているので、今回は以下のセクションに取り組んだ。
- 6 Getting started with Continuous Integration, Deployment & Delivery
- 7 Learn Azure DevOps - Continuous Integration, Deployment & Delivery Docker
- 8 DevOps on Azure AKS, Kubernetes Clusters - Docker, Azure DevOps & Terraform
- 10 Learn Azure DevOps with Boards and Backlogs
自分がスキップしまくったせいかもしれないけれど、Azure DevOpsの全体感が本Udemy講座ではわかりにくかった。
Udemy視聴前に読んでおくと良い記事
いきなりUdemy講座を視聴するのではなく、まずはこちらでAzure DevOpsについて概観しましょう。
- https://qiita.com/mstakaha1113/items/f9fad71b8bd33e77d9ce
- https://qiita.com/mstakaha1113/items/efdef712f54281a8a953
CI / CD プロセス
Continous Integration
CIのプロセスは以下の通り。
- Code Commit
- Unit Tests
- Code Quality
- Package
- Integration Tests
Continous Deployment
CIのプロセスに、DeployとAutomated Testsが入っている。
- Code Commit
- Unit Tests
- Integration Tests
- Package
- Deploy
- Automated Tests
Continous Delivery
Continous Deploymentのプロセスに加えて、UATチームやTestingチームが承認を行い、ステージング環境や本番環境にデプロイされる。
- Code Commit
- Unit Tests
- Integration Tests
- Package
- Deploy
- Automated Tests
- Testing Approval
- Deploy Next
- ...
CI/CDで利用されるツール
- Code Commit
- Git Hub
- Unit Tests
- PyTest
- Integration Tests
- Cucumber, Selenium, Protractor
- Package
- pip
- Deploy
- Jenkins, Azure DevOps
- Automated Tests (Smoke test, Load test, Performance test)
- Testing Approval
- Deploy Next
Azure DevOpsでのパイプライン
- Azure DevOpsには
Pipelinesの配下にPipelinesとReleasesが存在する。 Pipelinesはビルドパイプラインのことで、ソースコードからアーティファクトを生成するのに利用する。例えば、Dockerイメージを生成したりするのに利用する。単体テストや結合テストも自動化して実施する。- 一方、
Releasesは、ビルドパイプラインで生成したアーティファクトをあるステージに展開する。例えば、デスクトップアプリケーションならインストール作業のこと。
- The Azure DevOps Server provides two different types of pipelines to perform build, deployment, testing and further actions.
- A Build Pipeline is used to generate Artifacts out of Source Code.
- A Release Pipeline consumes the Artifacts and conducts follow-up actions within a multi-staging system.
ビルドパイプライン
ビルドパイプライン作成の流れ
ビルドパイプラインの定義
パイプラインYAMLファイルに、CI/CD プロセスを記述する
trigger: - main pool: vmImage: ubuntu-latest steps: - script: echo Hello, world! displayName: 'Run a one-line script' - script: | echo Add other tasks to build, test, and deploy your project. echo See https://aka.ms/yaml displayName: 'Run a multi-line script'
YAMLファイルには以下のような項目を定義する
trigger
- 継続的インテグレーションのトリガー
- ↑の例だと、triggerに
mainが指定されている。この場合、mainブランチに何らかの変更があった場合に、このパイプラインが実行される。
pool
- https://learn.microsoft.com/ja-jp/azure/devops/pipelines/agents/agents?view=azure-devops&tabs=browser
- 特に指定しない限り、このパイプラインのジョブが実行されるプール
- パイプラインの実行に使用されるコンピューティングをエージェント(Agent)と呼ぶ
- poolでは、エージェントプールの定義を行う
- ↑の例では、エージェントプールで使用するVMのイメージとしてUbuntuを指定している
- https://learn.microsoft.com/ja-jp/azure/devops/pipelines/agents/pools-queues?view=azure-devops&tabs=yaml%2Cbrowser
- ↑のリンクの通り、エージェントプールを設定することができる
steps
- このジョブで実行するステップのリスト
script
- 実行したいスクリプトを記述する
ビルドパイプラインの構成
パイプラインでは以下のような階層でタスクを定義できる。
ステージ、ジョブが定義されてなくても、タスクを定義できる。
パイプライン └── ステージ └── ジョブ └── タスク（ステップ）
ジョブの定義
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml
以下ではJob1とJob2というジョブを追加してみた。
Azure DevOps Pipelineで実行すると、Job1とJob2それぞれのステータスが表示される。
それぞれのジョブは異なるエージェント（VM）で実行される。ジョブ間に依存関係がない限り、各ジョブは並行して実行される。
jobs: - job: Job1 steps: - script: echo Hello, world! displayName: 'Run a one-line script' - script: | echo Add other tasks to build, test, and deploy your project. echo See https://aka.ms/yaml displayName: 'Run a multi-line script' - job: Job2 steps: - script: echo Hello, world! displayName: 'Run a one-line script'
ジョブ間の依存関係の定義
dependsOn:にジョブを指定することでジョブ間の依存関係を定義できる。
複数のジョブに対して依存関係を持たせることもできる。
現実には、Terraformでインフラを構築してから、アプリをインストールしたりする。そういった場合にジョブを指定した順に実行していく。
dependsOn:にステージ名を指定することで、ステージ間に依存関係を定義することができる。
jobs: - job: Job1 steps: - script: echo Hello, world! displayName: 'Run a one-line script' - script: | echo Add other tasks to build, test, and deploy your project. echo See https://aka.ms/yaml displayName: 'Run a multi-line script' - job: Job2 dependsOn: Job1 steps: - script: echo Hello, world! displayName: 'Run a one-line script' - job: Job3 dependsOn: Job1 steps: - script: echo Hello, world! displayName: 'Run a one-line script' - job: Job4 dependsOn: - Job2 - job3 steps: - script: echo Hello, world! displayName: 'Run a one-line script'
ステージの定義
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/process/stages?view=azure-devops&tabs=yaml
以下のようにステージを定義することができる。
stages: - stage: Build jobs: - job: FirstJobs steps: - bash: echo Build,FirstJob - stage: DevDploy <省略> - stage: QaDevloy <省略> - stage: ProdDeploy <省略>
これを実行すると、Azure DevOpsのパイプライン画面で、各ステージのステータスが表示される。
stepsの定義
stepsにはscrip以外にも、bashやpwshなど様々なタイプをサポートする。種類は↑を参照。
trigger: - main pool: vmImage: ubuntu-latest steps: - script: echo This runs in the default shell on any machine - bash: | echo This multiline script always runs in Bash. echo Even on Windows machines! - pwsh: | Write-Host "This multiline script always runs in PowerShell Core." Write-Host "Even on non-Windows machines!"
変数の定義
コンソール上やパイプライン定義、タスクのスクリプトで変数を定義できる。
パイプライン定義内で変数を定義する
以下のようにパイプライン定義内で変数を定義することもできる。
jobs: - job: B dependsOn: A variables: env: Dev
変数のスコープ
さまざまなスコープで変数を設定できます。
- ルート レベルで、パイプライン内のすべてのジョブで使用できるようにします。
- ステージ レベルでは、特定のステージでのみ使用できるようにします。
- ジョブ レベルでは、特定のジョブでのみ使用できるようにします。
定義済みの変数
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml
↑の通り、Azure パイプラインで定義されている変数がある。
例えば、ビルドしたパイプラインの名前をログに表示するには、Build.DefinitionName変数を使って、echoで表示させることができる。
stages: - stage: Build jobs: - job: FirstJobs steps: - bash: echo $(Build.DefinitionName)
ログの表示
↑の手順で、各ステップの個々のログを表示できる。
タスクアシスタント
使いたいタスクを簡単に追加できる。
ファイルのコピー
stepsにtaskとして、CopyFiles@2を定義することで、ファイルをコピーすることができる。
stages: - stage: Build jobs: - job: FirstJobs steps: - bash: echo $(Build.DefinitionName) - task: CopyFiles@2 inputs: SourceFolder: '$(Build.SourcesDirectory)' Contents: | **/*.yaml **/*.tf TargetFolder: '$(Build.ArtifactStagingDirectory)'
ビルド成果物の発行
stage間でビルド結果を共有したいことがある。
そういった場合には、task: PublishBuildArtifacts@1を使用する。
steps: - task: CopyFiles@2 inputs: contents: '_buildOutput/**' targetFolder: $(Build.ArtifactStagingDirectory) - task: PublishBuildArtifacts@1 inputs: pathToPublish: $(Build.ArtifactStagingDirectory) artifactName: 'drop' publishLocation: 'Container'
ビルド成果物とは？
- ビルドによって生成されたファイル
- 例: .dllや.exeなど
ストラテジー
- マトリックスを使用すると、それぞれ異なる入力を持つジョブのコピーが生成されます。
- これらのコピーは、さまざまな構成またはプラットフォーム バージョンに対するテストに役立ちます。
strategy: matrix: Python35: PYTHON_VERSION: '3.5' Python36: PYTHON_VERSION: '3.6' Python37: PYTHON_VERSION: '3.7' maxParallel: 2 steps: - script: echo Running on $(PYTHON_VERSION) displayName: 'Run a one-line script'
- このマトリックスでは、"Build Python35"、"Build Python36"、"Build Python37" の 3 つのジョブが作成されます。
- 各ジョブ内で、PYTHON_VERSION という名前の変数を使用できます。
- "Build Python35" では、変数は "3.5" に設定されています。 同様に、"Build Python36" では "3.6" に設定されます。
- 同時に実行されるジョブは 2 つだけです。
デプロイジョブ
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/process/deployment-jobs?view=azure-devops
- YAML パイプラインでは、デプロイ ジョブと呼ばれる特殊な種類の ジョブ にデプロイ手順を配置することをお勧めします。
- デプロイ ジョブは、環境に対して順番に実行される手順のコレクションです。
- デプロイ ジョブと従来の ジョブ は、同じステージに存在できます。
stages: - stage: DevDeploy jobs: - deployment: DeployToDevelopment environment: Dev strategy: runOnce: deploy: steps: - script: echo deploy - stage: QADeploy jobs: - deployment: DeployToQA environment: QA strategy: runOnce: deploy: steps: - script: echo deploy
承認とチェックの定義
- 承認チェックを使用してステージを実行するタイミングを手動で制御できます。
- 例えば、environment（環境）に対して、「承認とチェック」を作成すると、承認されるまでステージの実行を待機させる。
- これによって承認されたもののみデプロイするということができるようになる。
ビルドパイプラインの無効化
https://www.ntweekly.com/2022/01/25/how-to-disable-azure-devops-pipeline-temporarily/
作成したパイプラインは↑の手順で無効化できる。
サービス接続の作成と使用
DockerHubなどの外部サービスと接続するためには、「サービス接続」を作成し、パイプライン定義で使用する。
サービス接続の作成
サービス接続の使用
Dockerをビルドしてみる
- DockerHubへのサービス接続を作成する
- パイプラインで、サービス接続を使用する
trigger: - main resources: - repo: self variables: tag: '$(Build.BuildId)' stages: - stage: Build displayName: Build image jobs: - job: Build displayName: Build pool: vmImage: ubuntu-latest steps: - task: Docker@2 displayName: Build an image inputs: containerRegistry: 'docker-hub-test' repository: 'test2023' command: 'buildAndPush' Dockerfile: '**/Dockerfile' tags: '$(tag)'
↑の例では、DockerイメージのタグにビルドIDを指定している。
Library
ライブラリでは、変数グループとセキュアファイルを設定できる。
変数やファイルへのアクセス制御ができるため、Azureへの接続情報などを安全に保管し、パイプラインで使用できる。
変数グループやセキュアファイルにアクセスできるパイプラインを制限することができる。
Variable group
Secure files
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/library/secure-files?view=azure-devops
リリースパイプライン
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/release/?view=azure-devops
リリースパイプラインでは、ビルドパイプラインで作成したアーティファクトをAzure Appサービスなどにリリースする。
例えば、次のようなリリース例がある。
- PythonやJavaのアプリケーションをAzure Appサービスにデプロイ
- コンテナ化したアプリケーションをKubernetesクラスタにデプロイ
- Azure Functionsへのデプロイ
- ARMテンプレートを利用したAzureリソースの作成
- Terraformを利用したAzureリソースの作成
Terraformを利用したAzureリソースの作成
https://learn.microsoft.com/ja-jp/azure/developer/terraform/best-practices-integration-testing
Terraformを利用したAzureリソースの作成をPipelinesを利用して実現する。
PipelinesでTerraformを実行してAzureリソースを作成するには、PipelinesでTerraform CLI（terraform initやterraform apply）を扱えるようにするためのプラグインをイネーブルする必要がある。
以下の流れでPipelinesを作成する。
Terraform CLIを実行するのにあたって、AzureのクライアントID、クライアントシークレット、SSH公開鍵ファイルをパイプラインYAMLに渡してあげる必要がある。
クライアントID、クライアントシークレットをPipelinesに渡すのには、Azure PipelinesのLibraryのVariable groupを利用する。
一方、SSH公開鍵ファイルを渡すにはAzure PipelinesのLibraryのSecure filesを利用する。
terraform initを実行するパイプライン定義は以下のようになる。
以下では、.tfstateファイルをAzure Storage Account上に作成している。リソースグループやストレージアカウントも一緒に作成している。
trigger: - main pool: vmImage: ubuntu-latest steps: - script: echo Azure Terraform! displayName: 'Run a one-line script' - task: TerraformCLI@0 inputs: command: 'init' workingDirectory: '$(System.DefaultWorkingDirectory)/configuration' backendType: 'azurerm' backendServiceArm: 'Pay-As-You-Go (e595aee6-f9b8-450f-b9d3-73768a2fd47a)' ensureBackend: true backendAzureRmResourceGroupName: 'terraform-backend-rg' backendAzureRmResourceGroupLocation: 'westeurope' backendAzureRmStorageAccountName: 'azuredevopsterraformbackend20230311' backendAzureRmContainerName: 'dev' backendAzureRmKey: 'terraform-dev.tfstate' - task: TerraformCLI@0 inputs: command: 'apply' workingDirectory: '$(System.DefaultWorkingDirectory)/configuration' environmentServiceName: 'Pay-As-You-Go (e595aee6-f9b8-450f-b9d3-73768a2fd47a)' commandOptions: '-var client_id=$(client_id) -var client_secret=$(client_secret) -var ssh_public_key=$(publickey.secureFilePath)'
Azure DevOps Demo Generator
https://azuredevopsdemogenerator.azurewebsites.net/
https://qiita.com/dz_/items/736bfd7be1478d638518
Azure DevOps Demo Generatorでリファレンスプロジェクトとなるプロジェクトを作成することができる。
Azure DevOps Demo Generatorでリファレンスプロジェクトを作成すると、作成済みのDashbords, Wiki, Boards, Repos, Pipelinesのサンプルを参考にすることができる。
Boards
以下の記事を読むのがよい。
https://qiita.com/mstakaha1113/items/44458046d5a8568559b5
https://qiita.com/mstakaha1113/items/2c857e85ed6203d93028
https://qiita.com/mstakaha1113/items/9e0be0aaa5db89dd5ca9
Sprint
Query
指定した条件を満たすWork itemを探すクエリを作成できる。
作成したクエリは保存して、再度同じ条件で検索できる。
Repos
https://qiita.com/mstakaha1113/items/e2c6ef2622bc6cc0b0ef
コードリポジトリ
