kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Azure PipelinesでAzureのREST APIを呼ぶ

これはAzure DevOpsアドベントカレンダー19日目の記事です。

qiita.com

というちぇんわさんの無茶ぶり読者からのご質問があったので、簡単にやってみました。

Azure Pipeline task to call Azure REST API

難しいことはなくて、Azure PipelinesにPowerShellタスクを追加して、普通にPowerShellでのREST API呼び出しているだけです。もちろんアクセストークンなんかはこんな生書きしてはいけません(笑)。variablesか、Libraryに入れておくのが望ましいです。

一つ悩ましいとすれば「どうやってAzureのトークン取るの?」ということですが、今回の場合、AzureのREST APIのリファレンスには"Try It"というボタンがついているので、そこから持ってきました。

例えばVirtual Machinesの一覧を取るAPI。

docs.microsoft.com

このトークンの権限はちょっと調べてないですが、同様のことはAzure-CLIでもできます。Try Itからサインアウトしてもキーは使えていました。

docs.microsoft.com

qiita.com

ただまぁどうしてもRESTじゃないといけないということはあると思いますが、簡単にやるならAzure PowerShellタスクやAzure-CLIタスク使うとこの辺の面倒全部見てくれる(Login-AzureRmAccountコマンドレット不要)ので、そっちのほうがいいんじゃないかなと思いました。

docs.microsoft.com

docs.microsoft.com

Azure DevOpsの出来合いプロジェクトを簡単に作る方法

これはAzure DevOps アドベントカレンダー17日目の記事です。

qiita.com

Azure DevOpsを使えば簡単にプロジェクトを作れるのですが、実際どんな感じでどんなものを作っていけばいいのかわからないことも多いと思います。そんなあなたにデモ用のプロジェクトを作るサイトがMicrosoftから用意されています。

azuredevopsdemogenerator.azurewebsites.net

f:id:kkamegawa:20181217051657p:plain

Sign Inからデモプロジェクトを作りたいアカウントで認証します。

f:id:kkamegawa:20181217052505p:plain

対象のAzure DevOpsへのアクセス権限が要求されます。ほぼ全部の機能への権限を必要とされますが、これはしょうがないので、許可します。

f:id:kkamegawa:20181217053536p:plain

テンプレートによってはAnalytics拡張機能や、ほかの拡張機能が必要になります。たいていは自動的にインストールされますが、有償のものは自動的に追加されないので、注意してください。

f:id:kkamegawa:20181217055527p:plain

テンプレートは多様なものが用意されています。一般的なシナリオ、DevOps Labsのもの、アーカイブしたものをアップロードとかもできます。

f:id:kkamegawa:20181217055608p:plain

テンプレートもScrum, Agile。開発言語やミドルウェアもASP.NET(Core)やJava、node.jsといろいろそろってます。

f:id:kkamegawa:20181217055621p:plain

DevOps LabsではDevOps関係のプラクティスに関係するテンプレートが用意されています。DeploymentGroupsはIaaSへの大規模展開を支援する機能ですね。

WhiteSource-Boltは有償ライセンスが必要ですが、意図しないオープンソースファイルの混入をチェックするツールです。

ReleaseGatesはリリース時にリリース先の環境をモニタリングして展開の許可を自動的に判断する機能ですね。 大規模展開のBlue-Greenデプロイメントに使うと便利です。

f:id:kkamegawa:20181217055717p:plain

保存したファイルをアップロードする機能ですが、あまり使わないでしょうかね。

f:id:kkamegawa:20181217061130p:plain

テンプレートを選択したら、Create Projectで作成します。

f:id:kkamegawa:20181217061348p:plain

ちょっと待つと出来上がります。

f:id:kkamegawa:20181217061732p:plain

チームのSummaryにも情報が出ていますね。Work Itemが121個があり、二つのPull Requestがあるということがわかります。

f:id:kkamegawa:20181217061909p:plain

Work Itemもずらっと作られています。

f:id:kkamegawa:20181217062938p:plain

作業用のPull Requestも作られています。

f:id:kkamegawa:20181217063104p:plain

このPull Requestを処理すると、登録済みのビルド定義が実行されます。いくつかのタスクは古いバージョンが使用されているので、事前に直しておくのがいいでしょう。

ビルドが実行されたらReleaseが自動的に実行されます。

f:id:kkamegawa:20181217062635p:plain

Releaseを使うとき、サブスクリプションや展開先を指定しておいてください。

という感じで、そここその規模のプロジェクトが作れるので、結構便利です。典型的なサンプルなので、CIやCDの作り方やWork Itemの管理とかががわからないときは参考にすればいいんじゃないでしょうか。

参考:

docs.microsoft.com

Azure DevOps 2018/12/4の更新

この記事はAzure DevOpsアドベントカレンダー12日目の記事と兼用です。

qiita.com

Azure DevOps Sprint 144リリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

今回の目玉はAzure Boards as a Serviceですかね。ということでAzure Boardsを単独で使えるようになりました(もしくは既存のアカウントから独自に切り出して公開)。GitHub issueのほうが手軽にできて楽だという人は別に無理に使う必要はないんですが、issueになれていない人(といってもGitHub中心でやってた人はそうでもないと思うけど)、とか、個別の登録済みクエリでさくっと見たいとかいう人はまぁいいんじゃないかなと思います。

ほかにもGitHubとの連携がずいぶん増えました。GitHubリリースへのタスク(marketplaceには前からありました)とか、VS CodeやWebでのYAML支援(これは正直めっちゃうれしい)、あとはAzure DevOpsのサービス正常性ポータルが独立しました。

Regionとはいっても、USでは少なくともNorthとSouthの二つあるはずなのですが、まとめてUS Regionとなっているようです。

PythonのパッケージもArtifactsに入りました。使っている人にはうれしいかなと思います。

ではまた三週間後…といっても、USはクリスマス休暇に入るはずなので、おそらくSprint 145をスキップして、146とまとめて来年の更新になるんじゃないかなと思います。

Translate to Japanese to Azure DevOps release note ...

Azure DevOpsのセキュリティ設定

これはAzure DevOpsアドベントカレンダー3日目の記事です。

qiita.com

Azure DevOpsで複雑だと言われる点の一つがセキュリティ周りの設定です。東京と大阪で来年このネタでしゃべるつもりですが、チラ見せみたいな形でご紹介します。

jazug.connpass.com

jazug.connpass.com

大前提

会社組織であればAzure DevOpsはAzure ADベースで動かしましょう。特にOffice 365を使っていればグループ管理が格段に楽です。

ただ、グループの反映はオンプレミスADと違って、1時間くらいかかるようなので、リアルタイム反映は期待しないほうがいいようです。

Organization

f:id:kkamegawa:20181203204821p:plain

ユーザー追加設定です。まずはここに登録しないと始まりません。Azure ADベースで運用しているのであれば、Azure ADのグループごとに追加していったほうが楽です。数人であれば、ちまちま手作業でもいいでしょう。

会社であれば、REST APIを使って管理するのもいいと思います。

f:id:kkamegawa:20181203204831p:plain

Azure DevOps のOrganization(dev.azure.com/Organization)全体の設定です。全プロジェクトに関わるので慎重にしてください。一名では何かの時に不安なので、複数登録しておくことをお勧めします。

f:id:kkamegawa:20181203204837p:plain

アプリケーションからの接続方法を許可する設定です。Alternative AuthenticationはSSHやAzure AD認証がなかった頃、MSアカウントでの認証ができないような環境向けに用意されていた脆弱な方法です。現在はSSHやAzure AD認証(デバイスなど)ができるようになっているので、オフにすることを推奨します。

パブリックプロジェクトはプロジェクト単位で外部に公開できる機能です。組織では使うことはないかもしれないので、最初はオフにしておくといいでしょう。

仮に公開する場合でも、公開は「プロジェクト」単位です。Gitのリポジトリごとに公開できないので、注意してください。

Gitブランチ

f:id:kkamegawa:20181203204750p:plain

Gitのブランチごとにセキュリティの設定ができます。特徴的なのはbypass policies〜ですね。特定の条件に一致した場合、ポリシーをスルーできます。

ブランチポリシー

セキュリティとは少し違いますが、類似なので解説します。

Azure DevOpsではGitブランチごとにレビュワー設定、ビルドを通すという設定ができます。全部のブランチに設定すると大変なので、master, dev, releaseなどの重要なブランチにのみ設定してください。

f:id:kkamegawa:20181203205056p:plain

最小限のレビュワー、作業項目のリンクを必須にする、マージ戦略を強制するといった設定です。

f:id:kkamegawa:20181203205049p:plain

コミット前にビルドが通るかどうかのチェックするビルド定義を指定します。Require approval from external servicesでは例えば、マージ前にセキュリティやコンプライアンスチェックを行うようなサービスを呼び出す、未解決のworkitemがあるかどうかを判定する独自サービスとの連携行います。

こういうのはAzure FunctionsやAWS Lambdaを使うといいですね。

プロジェクトセキュリティ

Project Settingsのページから実施します。

f:id:kkamegawa:20181203204805p:plain

プロジェクトの基本的なセキュリティ設定です。以前作られたプロジェクトではBuild Administratorに入っていないとビルド定義が作れなかった(外部サービスからも同様)のですが、最近の変更で変わりました。古いプロジェクトは明示的に変更する必要があります。

Azure Pipelines

ビルドとリリースにもセキュリティ設定があります。どちらもだいたい同じです。それぞれの定義の三点リーダ(…)をクリックすると出てくるSecurityから呼び出せます。

f:id:kkamegawa:20181203211014p:plain

f:id:kkamegawa:20181203211020p:plain

内容はどちらもだいたい同じで、セットするかどうかだけですね。

ブログでは簡単にまとめましたが、セッションではもうちょっとシナリオベースでお話しようかなと思っています。