Azure DevOps 2021/5/26の更新

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

docs.microsoft.com

今回は機能は少なめでしたけど、Delivery Plans 2.0が正式版ということでエントリーは長めです。でもdeepl翻訳なんかよくなってるようで直すところ少なかった…。

Delivery Plans 2.0が正式版になって、拡張機能ではなくなりました。拡張機能であるが故の制約がほとんどなくなって便利になります。少し大きいチームを運用するときとか絶対に欲しい機能だと思いますので、ぜひ使ってみてください。Dependency Trackingもバックエンドや外部に依存するような機能があるときはすごく便利です。

Protected ResourceがVariable Groupsおよび、Secure Fileにも適用されました。これもとてもいいですね。私Protected Repositoryの動画作ろうと思っていたのですが、前のSprint 186が一向に展開されずまだかまだかと思っていたら単にブラウザーのキャッシュの状態か何かで出てないだけで、とっくに展開されていたという…予定通り2‐3週間で展開しているようです。

この件で調べていて教えてもらったのですが、海外のMVPが作っているTfsCmdletsの中にあるGet-TfsVersionというコマンドレットを使えば現在展開されているAzure DevOpsのバージョンがわかるのだそうです。試してみてください。オンプレミスでも使えるそうです。

github.com

全Azure Pipelinesユーザー待望のYAMLエディターでTemplateがようやくサポートされることになりました（Yes!）。現在のところPreviewを有効にして、すでにつくられているものでいくつかの限定的な検証ができるだけですがこれができるだけでもえらい助かります。パスの位置や引数とかどうしても間違えやすいですしね。私のところにはまだ来てないですが、来たら試してみます。

Ubuntu 16.04のEOLに伴い、Azure Pipelinesからも消えます。移行を促すために一定時間短い間わざとUbuntu 16.04を使ったパイプラインを失敗させるそうです。日本時間では夜中の2時とかになるので、もしも夜中の本番デプロイを実行している場合は気を付けてください。

同じくUbuntuイメージにインストールされる.NET SDKのパッチが最新版のみになるそうです。あーあのSDKの名前そういうつけ方だったのか。古いSDKに依存しているような場合（といってもセキュリティFIXだから早めの移行を）は注意してください。

ではまた三週間後。

Translate to Japanese to Azure DevOps release not…

仮想化されたドメインコントローラーでネットワークプロファイルがパブリックになってしまう

新しく作ったVMのドメインコントローラーのネットワークプロファイルがどうしてもパブリックのまま変わらないので困っていたのですが、調べたらNetwork Location Awarenessサービス（ネットワークプロファイルの判定を行うサービス）の起動がドメインサービスよりも早すぎてパブリックになってしまうことが原因ということです。

サービスが依存しているのに先に起動してしまっているのが悪いので、依存関係を追加するか、サービスの起動を自動から自動（遅延起動）にするという方法があります。今回は両方やってみました。

sc config nlasvc  start= delayed-auto
sc config nlasvc  depend= NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS

※：DNSとNTDSが新規で追加する依存関係です

docs.microsoft.com

さしあたりNLAサービスを再起動（Network Listsも一緒に再起動かかります）すると解消することはわかっているので、これでしばらく様子を見てみます。

出展：serverfault.com

業務形態別Azure Reposのforkパターン

Azure ReposのGitもGitHub同様にforkできるのですが、あまり使われてないんじゃないかなぁ、という個人的な印象があります。チームプロジェクトと、Gitのレポジトリわかりづらいかもしれません。そこで用途別のforkについてこうしたらいいんじゃないかなケースでまとめてみます。

docs.microsoft.com

請負パートナーと同じorganizationで作業する

日本の法律的に請負で契約している会社のメンバーに対しては作業指示に関して制限があります。そんなときに使えるのがチームプロジェクトを超えたforkです。メリット。

• Environmentやtask, Libraryなどの名前はプロジェクトローカルなので、同じ名前が使える
• サブスクリプション単位で費用分割可能
• Service Connectionもそれぞれ分割可能
• 権限もそれぞれのチームで設定可能で、お互いのチームでメンバーの検索はできない

デメリット

• 別のチームを管理する人が必要になるので面倒
• マネージメントする人が割と大変

正直法律上の制限のため仕方ない場合を除いてチームプロジェクトを超えるforkはお勧めできません。

同一組織内の開発者で作業する

チームプロジェクトに別のGitレポジトリーを作ってforkします。多分これがだいたいいいんじゃないかなぁとは思います。メリットはこんなところでしょうか。

• GitHubなどとだいたい同じのforkの感じで使える
• しかし、GitHubとは違ってタスクは同じAzure Boardsで管理できる
  • 作業項目がごっちゃになってわかりづらくなるので、area pathとチーム構成で権限を設定するのがおすすめです
• パイプラインも別管理できる（マージするときに入れないようにしよう）

デメリット

• Environment, Task, Libraryを共有することになるのでネーミングルールとパイプライン定義重要
• パイプラインがごっちゃになるので、フォルダー分け、権限管理もやりましょう。
• Service Connection使ってサブスクリプションを別管理するときはService Connection単位で使えるパイプラインを明示的に設定するのがおすすめ
• 重要なリソースであればapproverも設定して、connectionに対して承認設定しましょう。

割と万人向けではあるかもしれないけど、管理で混乱しないようにしましょう。

チーム開発向け

モノレポでブランチのみを使った開発ですね。個人もしくは数人、Azure Web Appみたいにスロットを元から持っているようなPaaSへのデプロイであればこの携帯で十分じゃないかなと思います。シンプルでわかりやすい。

モノレポの場合、10GB までという制限があります。ソースコードだけであればここまで行くことは多くないと思いますが、ドキュメント、画像、動画などを入れてしまうと割といってしまうので気をつけてください。

docs.microsoft.com

終わりに

パッと思いつく感じのforkでまとめてみましたが「こんな感じでやってる」とか「こういう場合はどうすれば」とかあればコメント, Slack, Twitterなどで教えてください。

Azure DevOps 2021/5/4の更新

May be 4th with You!(5/4リリースだったので。私はSW派です) Azure DevOps Sprint 186リリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

今回、Azure Repos（Gitのみ）を保護されたリソースとして定義できるようになりました。これは非常にうれしい。一つ前のエントリーでもお話したセキュリティ＆コンプライアンスの欠点のひとつとして、「レポジトリーはreader(チームプロジェクトに参加していれば大体つく)権限があれば参照できてしまう」という仕様がありました。

kkamegawa.hatenablog.jp

例えばリリース用のYAMLテンプレートをどこかのレポジトリーで集中管理させて、特定のパイプラインのみ参照させたいということが基本的に難しかったのですが、この機能を使えば実行時の検証が入るのでとても助かります。

PAT管理のAPIが一般提供可能になるの早かったですね。前のスプリントでプレビューになったばかりなのに。PAT管理は悩みの種でしたが、テナントとの連携で楽になりそうです。

Artifactsのごみ箱に入ったフィードが消せるようになったのもストレージ節約になってうれしいですね。

ではまた三週間後。

Translate to Japanese to Azure DevOps release not…