kkamegawa's weblog

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

Azure DevOps Server2020リリース&インストール

Azure DevOps Server 2020がリリースされましたね。

docs.microsoft.com

以前のオンプレミスではリリースノート翻訳されていたのに、されなくなってしまった…予算か?

今回からWindows Server 2012 R2以前のOSが非対応になっているので、ハードウェアの移行しないといけない人も多いと思います。Reporting Serverも非推奨になりつつあるので、以前よりは移行が簡単です(私はもう使っていません)。

tfsadmin.exeでバックアップをとってもいいですがSQL Serverから以下のデータベースをバックアップします。

  • [AzureDevOps | Tfs]_コレクション名
  • [AzureDevOps | Tfs]_Configuration
  • Tfs_Warehouse(これはなくてもいいかも)

新しいOSにSQL Serverをインストールします。せっかくなので、SQL Server 2019を使いましょう。

コレクション名のデータベースは複数ある可能性があるので、忘れずにもれなくバックアップ&リストアしましょう。

そのあと、Azure DevOpsのインストールを行い運用環境のアップグレードを選択して実行すればいいです。

アップグレードプロセスそのものは2019とほぼ変わりありません。TFS 2018との違いはAzulのJDKをダウンロードしてくることくらいですかね。ちなみにSQL Server 2019インストール時にBig Data Clusterを有効にすると別のJDKがインストールされるので、二つはいることになります :-)。

Azure DevOps 2020/10/1の更新

Azure DevOps Sprint176のリリースノートの翻訳を行いました。オリジナルはこちらからご覧ください。

docs.microsoft.com

今回いよいよ、organizationレベルでGitのデフォルトブランチ名を変更できるようになりました。GitHubも10/1から新規作成したレポジトリーはmainになってますね。MS管理の既存レポジトリーもわりとmainに変わっているようです。upstreamからfetchしようとして、「もう変わったんだ」とちょっとびっくりしました。

docsのデフォルトブランチのように、もともとmasterではなく、liveと言うブランチ名使っていたところもありますね。

PRのコメントのみの読み書き可能なPATのスコープは面白いですね。確かにBotに対してはコメントだけ読み書きできれば十分なこともあるので、便利に使えるケースもあるだろうと思います。token where compromisedと言う単語の訳語、deepl, Googleとも危殆化と言う訳語を提案してくれていましたが、日本語としてどうもイメージできなかったので、単純に「漏洩」みたいにしています。

日本語の会見でも「漏洩したとしても、直接使えるものではないから直ちに危険ではない」みたいなイメージでしょうか。

@matarillo さんから教えてもらいました。HUNTER x HUNTERのG.I編みてたおかげで「妥協」と言う訳があることは知っていましたけど、「トークンが妥協?」とちょっと首を傾げてました。

GitHubのレポジトリーに対するdraft PRのvalidationもGitHubのレポジトリ中心で生活している場合はとても便利そうです。

ではまた三週間後。

Translate to Japanese to Azure DevOps release not…

GitHubのProjectを使って、Azure DevOpsの複数のプロジェクトを集約して管理する

はじめに

前のエントリー公開後、このようなお便りをいただきました。ちょうど一回やってみたかったことなので、書いておきます。

簡単な解決方法

簡単な方法としてはクエリー作るときにQuery Across Projectsにチェックを入れることです。

docs.microsoft.com

f:id:kkamegawa:20201004172151p:plain

チェックしない場合。

f:id:kkamegawa:20201004172147p:plain

チェックした場合。商品一覧の表示というfeatureが追加されていますね。これは別のプロジェクトのWork Itemです。もっとも簡単なのはこのパターンでしょう。

Azure DevOpsはOrganizationをまたがるのはユーザー管理の観点から今のところサポートされていません。

でもこうじゃなくて、もうちょっと全体を俯瞰してみたい場合、GitHubを使ってやってみようかなという方法を紹介します。

docs.microsoft.com

GitHub Projectを使って管理する

GitHub Projectという機能があります。issueをまとめて管理するカンバンですね。でも今回はAzureの機能を使うので、github-actions-issue-to-work-itemというActionを使ってみましょう。

github.com

Azure Boardsアプリをインストールする

docs.microsoft.com

事前にAzure Boardsアプリをインストールしておいてください。

GitHub接続を作る

f:id:kkamegawa:20201004172059p:plain

Service ConnectionからGitHubへの接続を作っておきます(たぶん要らないとは思いますが)。

f:id:kkamegawa:20201004172104p:plain

GitHub Projectを作る

f:id:kkamegawa:20201004172108p:plain

告知用のレポジトリからProjectを作ります。

f:id:kkamegawa:20201004172128p:plain

レポジトリからActionsを作ります。接続するプロジェクトを選びます。YAMLのサンプルはレポジトリにあるのでそのままぱっくんちょすればいいです。

サンプルはAgileプロセス前提で作っているので、ScrumやBasicを使う場合、ado_witや、ado_active_statusを該当プロセスの値に変えることを忘れないでください。

API Keyを作る

docs.github.com

GitHubとAzure DevOps側にPATを作っておく必要があります。

f:id:kkamegawa:20201004172112p:plain

Azure DevOpsではrepoのRead & Write(余計なManageまでついていますが)だけ必要です。

f:id:kkamegawa:20201004172120p:plain

GitHubではrepoのフルが必要です。

f:id:kkamegawa:20201004172124p:plain

f:id:kkamegawa:20201004172116p:plain

作ったレポジトリにADO_PERSONAL_ACCESS_TOKENGH_PERSONAL_ACCESS_TOKENの二つのシークレットを作って、PATを貼り付けます。

issueに追加

f:id:kkamegawa:20201004172143p:plain

GitHub側でIssueを作ると、登録したActionsが動いて、自動的にAzure Boardsに反映されます。

f:id:kkamegawa:20201004172138p:plain

Azure Boardsに作られた例。これでAssignやAreaなどを直せばいいでしょう。

f:id:kkamegawa:20201004172133p:plain

作られたissueはProjectに登録されるので、わかりやすいです。Issueのステートと連動するので、GitHub側でCloseすれば自動的に変更されます。

まとめ

GitHub Projectsでは複数のレポジトリのissueの登録ができます。仕事などでGitHubのorganizationを運用している場合、この方法でまとめていけばいいんじゃないかなと思います。

ちょっとどっちが正になるかわかりづらいかもしれないですが、大きなプロジェクト全体で見るようなレベルのものに関してはGitHubで作っておく、そうじゃないものはAzure Boardsで管理するみたいなこともできるので、場合によっては便利に使えるかもしれません。

タスク管理をスプレッドシートからAzure Boardsにしたい人向けの話

ご質問コーナーに以下の質問をいただきました。まとめていたら回答が遅くなってしまいました。

Azure Boardsの効果的な導入方法を教えてください。 現状、Azure DevOpsを使っているのにほぼAzure Reposしか使っていない状態です。 手始めに、Azure Boardsを使えたらと思っているのですが、全くの五里霧中です。 なお、当方はGoogle Sheetでタスク管理をしています。

割とあるケースだと思います。スプレッドシートで管理って誰でもパッと見えるから、(特にタスクを見たいだけの人にとっては)やりやすいように見えるんですよね。別のタスク管理ツールで管理していても「Excelで一覧をだしてくれ」といわれることあると思います。Azure Boardsでこうやっていけばいいんじゃないかなという例をご紹介します。

最初はチーム編成になります。ご質問のチーム状況がかかれていませんでしたが、こういう感じでどうでしょうか。

f:id:kkamegawa:20201003125003p:plain

チーム分割するか、単一のチームでやるか決めましょう。最初は20人くらいまでならチーム分割しなくてもいいでしょう。実際にはもっと少なくてもいいとは思いますが、開発しているものとかにもよりますので、コミュニケーションコストを考えて。将来的にはなんらかの単位でチームに分割にすることをお勧めします。

最初からチームでリリースするものが分担されている場合は、チームを分けておくことをお勧めします。複数のチームが同じカンバンを見ていると、情報が見えていいこともありますが、混乱することがあるためです。

フロントエンドとバックエンドのように連携する必要がある場合、Dependency TrackerやDelivery Plansといった拡張機能があるのでお互いの状況を見やすくなります。

marketplace.visualstudio.com

docs.microsoft.com

Microsoftの人がハンズオンも作ってくれていますね。

www.slideshare.net

次はスプリントの計画を行いましょう。スクラムで使われるスプリントですが、最初はスクラムで始めるためではありません。

  1. いつどの作業を行ったか計画として記録する
  2. タスクがBoards上であふれかえるのを防ぐ

重要というよりも、使いづらくならないようにするために2が必須です。スプリントの日程を設定しない場合、一つのボードに作業がどんどんたまっていき、見づらくなります。

f:id:kkamegawa:20201003132343p:plain

f:id:kkamegawa:20201003133035p:plain

これ私のカンバンですが、スプリント作っているので、その期間にやるべきことがわかりやすくなります。タスクであふれかえって見づらくならないように最初は一か月単位とかで構わないのでスプリント計画を作りましょう。

スプリントは親子階層を作れます。チームプロジェクト管理画面から作成するスプリントは手作業で作ります。

f:id:kkamegawa:20201003125008p:plain

BoardからチームのSprintを作ります。

f:id:kkamegawa:20201003125012p:plain

親子階層がつくれます。Iterationの下にさらに作れます。たとえば2020年という階層を作ってその下に作っていくなどできます。

f:id:kkamegawa:20201003125017p:plain

こちらはプロジェクトの管理者が作ったイテレーションを登録する作業です。

チームのスプリントおよび、チームプロジェクトの管理画面から作れます。最初はチームスプリントから作ってもいいでしょう。

f:id:kkamegawa:20201003125021p:plain

こちらはプロジェクトの管理画面で作る場合です。こちらから作れば、全チームに共通のスプリントとなります。

スプリントを作るのはTeam AdministratorもしくはProject Administrator権限が必要なので注意してください。プロダクトを作っている場合、締め切りがあるはずなので、自分たちのスケジュール上切りのいいタイミングでスプリントを切ってしまえばいいです。慣れてきたら定期的なスケジュールになるように検討すればいいでしょう。

f:id:kkamegawa:20201003133525p:plain

スプリントを作ったらその期間内に実施するタスクを登録します。バックログ、タスクとありますが、最初はタスクだけでも構いません。やりたいことがあり、どんな機能や仕組みを作るのか、そしてさらに実際の作業(可能であればコミットして、リリースできる単位)にバックログ、タスクといった感じで割り当てます。このあたりはスクラムやアジャイルの本を読んでください。

f:id:kkamegawa:20201003133551p:plain

Taskに実際にコミットするような単位で作業を設定したら、Gitの場合まずタスクの関連付けでBranchを作ります。こうすることで、Gitでコミットすると、自動的にWork Itemとの関連付けが行われます。コミットメッセージにタスクのIDをつけなくてもいいので非常に楽です。

ビルド、テストが終わればプルリクエスト出して、masterにマージして、完了です。作業完了の時間はAzure DevOpsへ自動的に登録されています。

最初はこのような感じで始めるのがいいのかなと思います。慣れてきたら今度はみんなのスケジュールの登録とかいろいろできるようになります。