kkamegawa's weblog

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

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

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

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

OSS向けのAzure Pipelinesについて

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

qiita.com

別件で調べていたらサクラエディタのissueにAzure Pipelines を調査するというものがあったので、ネタにさせていただきます。実は自分ではOSS向けのAzure Pipelines使ってないので、間違っていたら教えてください。

ライセンス

オープンソースプロジェクトでは10並列、ビルド時間無制限のAzure Pipelinesが使えます。

Azure DevOpsの料金

典型的な例ではGitHubにすでにレポジトリを持っている人たちが使う、ということが考えられます。GitHubのMarketPlaceから追加してください。

始め方

docs.microsoft.com

GitHubの場合はこちらにファーストステップガイドが載っています。現在Azure PipelinesにサインアップするにはMSアカウントが認証用に必要になっています。もしも学生であれば、Microsoft Imagineの担当者にも相談してみてください。

AppVeyorなどでやっていた方はともかく、今までCIをやっていなかった方はGUIでの初期構築がいいと思います。その場合に注意すべき点はいくつかありますので、紹介します。

絶対パスをやめる

特に昔からのソースを保持している人にやっている人がいるんですが、特定のパスじゃないとビルドできないソースはこの手のCIサービスが使えません。Visual Studioを使っている場合、プロジェクトファイル内に絶対パスを書いていたらVisual Studioが用意しているマクロ($(SolutionDir)等)に移行しましょう。

あと、C/C++プロジェクトで多いですが、昔の伝統でincludeやlib環境変数を使って絶対パスに依存している例があります。もしくはプロジェクトファイルに移行していたとしても、絶対パスでincludeファイルを指定している例を結構見ます。

対策としては、Boostのような有名ライブラリであればNuGetに移行することです。そうすればincludeやlibはNuGetパッケージが解決してくれるので、この手の問題から解放されます。マイナーなライブラリの場合、自分で作るしかないですが…。

www.nuget.org

ビルド環境の注意点

環境が初期化される

CIサービスなので、ビルド環境は毎回初期化されます。したがって、docker pullやNuGetパッケージは毎回リストアですので、ローカルでやるよりも時間がかかります。また、Windows環境は2コアCPUのサーバーなので、ローカルでいいマシンを使っている場合、より差が出ます。

LinuxやWindowsではそもそも2コアサーバーですが、macOSのエージェントは実機で動いているようなので、性能が十分に出る可能性があります。.NET CoreやJavaScript、Java等プラットフォームに依存しないビルドだったらmacOSのほうが早いのかもしれません(未確認)。

ビルドマシンの制限

Azure Pipelinesのストレージは10GBなので、ゲームなどで大きなコンテンツをビルドしようとすると、容量が足りなくなるかもしれません。

docs.microsoft.com

管理者権限がないので、管理者として実行しないと動かないようなツールは使えません。

コンパイラー環境

そのほか、新しい環境は入っていますが、古い環境で使用者が少ないとなくなっていきます。例えばXcodeの8.0-8.3.2は2018/11いっぱいで使えなくなります。

Xcode 8.0-8.3.2 deprecation on Azure Pipelines hosted agents – Microsoft DevOps Blog

古いものを外部に維持してもらおう、ということはできず、むしろ積極的に切り替えていく必要があるため、古い環境こそ自分で維持する必要があります。かといって、新しすぎるものはロールアウトの都合上、少し遅れます。Azure DevOpsが3週間ごとにリリースされており、ビルドエージェントもそれに合わせて更新されていくので、新しいコンパイラーなどは少し待ってください。

英語OS

AppVeyorなどのCIを使っている方であればすでに対処しているかもしれませんが、ビルドマシンは日本語OSではありません。したがって、SHIFT-JISで保存しているファイルをビルドするとき、0x5c(表、ソ等)が文字列中に入っていると、コンパイラがエラーを起こします。

kkamegawa.hatenablog.jp

こちらに書いたのでみてください。

ビルド上限

6時間までです。

Azure DevOpsでの格納ポリシー

Pipelinesのみを使う場合であればビルドした結果を一時的にAzure DevOps内部に保持できます。これはCIであるPipelinesのビルドと、CDであるReleaseが分離されているため、一時的な受け渡し場所として使います。時間経過とともに消えますが、直近の一つの成功ビルドは残っています。成功して、問題なければGitHubのReleaseにPublishするなどしてください。