はじめに
AZ-400取ったので、苦手な部分を復習がてら記事化。
DevOpsとは
開発と運用が連携して開発する手法。開発と運用がそれぞれサイロ化しちゃっていると「新しいものを取り入れたいvs既存のルールに照らすと取り入れられない」になってしまい、新しいもの作り出せない状態になりがち->それなら連携してスピーディーにやっていこう！
……という流れだと理解している。定義はベンダや人によって全く同じにはならないけど、開発と運用が連携する、はベースにあるはず。
アジャイルやCI/CDはDevOpsを実現する方法の一部。組織文化の変革もDevOpsの実現には重要だけど、Azure試験の文脈だとリリースサイクルを短縮したりガバナンスを早い段階で利かせる(シフトレフト)ためにAzureのどんな機能を使えばいいか、というのが重要。
Azureの文脈のDevOps
Azure DevOps
DevOpsに関するサービス群
Azure Pipelines
CI/CD機能を提供するサービス。Node.js, .Net,など様々な言語に対応しており、PowerShellスクリプトを実行することもできる。Azure Pipelinesを使うにはAzure DevOps上でorganizationを作成する必要がある。
flaky test
コードや実行環境が同じなのに合格したり失敗したりとテスト結果が不安定なテストのこと。Azure Pipelinesではシステム検出またはカスタム検出が利用できる。システム検出はテストを再実行することで検出し、カスタム検出は自前の検出メカニズムをAzure Pipelinesと統合して検出する。
flakyとしてマークされているテストは手動でマーク解除も可能。
リポジトリ
Azure DevOpsシリーズにはAzure Reposがあるけど、GitHubと組み合わせることも可能。Azure ReposにはAzure Repos GitとAzure Repos TFVCがあるが、TFVCはクラシックパイプラインでのみサポートされる。
GitHubを使う場合、認証はGitHub App, OAUth, 個人用アクセストークン(PAT)の3種類が利用できる。
GitHub App…AzurePipelines IDで認証する。利用にはリポジトリに対してGitHub Appのインストールが必要インストールにはGitHub組織の所有者orリポジトリ管理者権限が必要。
OAuth…個人用GitHub IDで認証する。Checksなど一部の機能は利用できない。(利用したい場合はGitHub Appを使う)
PAT…個人用GitHub IDで認証する。OAuthとは異なり、Azure Pipelinesのアクセス許可を制御できる。
ブランチポリシー
修正や新機能の開発を行いつつメインブランチの品質を保つには、変更を加える際にはメインブランチから分離させて作業を行ったり、マージ前にソースコードの品質を確認したりすることが必要。
ブランチポリシーでプルリク時にレビュー担当者の承認を必須にする、マージの種類を限定する、といった項目を設定することで、ルールに沿っていないソースコードのマージを防ぐことができる。
機能ブランチ
新機能の開発やバグ修正作業をする際、ユーザごとにメインブランチをフォーク、ローカルで作業、コードをメインブランチにマージする……こともできなくはないが、他のユーザがどんな作業をしているか分かりづらい。
機能ごと(または修正するバグごと)にブランチを作成すると何やってるか確認しやすい。開発してみてやっぱやーめた、ってなったらマージしなければいいだけなので実験的な取り組みにも手を出しやすい。
ブランチ戦略をより詳しく知りたい場合は以下の記事がおすすめ。
おわりに(学習した所感)
今まで受けたAzure試験(AZ-104, 204など)は試験範囲のAzureサービスがあって、それはこういうときに使います、こんな設定項目があります、というのを整理したら太刀打ちできたという印象。一方AZ-400は品質と速さを両立させるためのグッドプラクティス、グッドプラクティスが生まれる前のバッドプラクティスを踏まえてないと頭に入れづらかった。(自分の専門がAZ-104, 305寄りなのもあるかもしれない)
AZ-400はAZ-104, 305と比較すると教材も少ないので、いかにMSのドキュメントを読みこめるか、ラーニングパスからリンクされていないドキュメントや、ときにMS以外のサイトのDevOpsプラクティスのドキュメントにあたれるかは重要だと思う。