こんにちは。 AZPower クラウドサービス開発本部 森です。
先日、Microsoft資格試験 AZ-400:Designing and Implementing Microsoft DevOps Solutionsを取得しました。
せっかくですので、これらの取得の際に作成した学習リソースを共有したいと思います。
長期にわたっての記事となりますので、大変ですがお付き合いのほどをよろしくお願いします。
AZ-400 とは
AZ-400は開発プロセスで必要となるさまざまなツール(簡単にいうとAzure DevOpsとGit, VSCodeあたり)やプラクティスの知識を持っていて、
Azureの管理・開発に精通しているということを試される試験です。
そのため、受験資格としてAZ-103, AZ-104(Microsoft Azure Administrator)またはAZ-203, AZ-204(Developing Solutions for Microsoft Azure)の資格を保有している必要があります。
AZ-400とMS Learn
私がAZ-400の取得に活用したのが、MS Learnです。
簡単にいえば、前述の前提資格を取得した方で、こちらのコンテンツの内容がひととおり理解できれば取得できるのではないかと思います。
ただ、2020年8月6日時点でAZ-400のラーニングパスにある記事はすべて英語でした。
そのため、この学習リソースを利用するには少し英語のハードルが高くなっています。
私はAZ-400の資格取得の学習の目的で翻訳しました。
せっかくですからこれらの翻訳結果共有したいとおもいます。
今後のAZ-400の受験に役立てていただければ幸いです。
ただ、翻訳は専門ではないので、微妙な翻訳になっているかもしれませんが、ご容赦のほどを…。
あと、記事中のリンクは記事のソースと同じになるように設定しましたので、リンク先は英語の記事になっています。
加えて、本家の記事では解説記事の最後に知識確認のためのテスト問題が出題されるのですが、この部分に関しては翻訳していません。（勉強用のリソース以外でしたので…）
DevOps プラクティスを発展させる
DevOpsとは、エンド ユーザーに対する価値を継続的に届けることを可能にする、人、プロセス、製品の総称です。
その価値の継続的デリバリーに必要なツールを与える一連のサービスがAzure DevOpsです。
Azure DevOpsを利用すれば、あらゆるアプリケーションをビルドし、テストし、クラウドまたはオンプレミスにデプロイできます。
透明性、共同作業、継続的デリバリー、継続的デプロイを可能にするDevOpsプラクティスは、今後のソフトウェア開発ライフサイクルとして広がることでしょう。
このラーニング パスでは、DevOpsの旅を始めることになります。 このチュートリアルの内容は次のとおりです。
- 現在のプロセスとテクノロジを評価する場合に利用する、Value Stream Map(バリュー・ストリーム・マップ）がどのように役立つかを確認する
- Azure DevOps Organizationに無料でサインアップする
- Azure Boardsを使った作業項目の計画および追跡方法を学習する
- 複数のアジャイル チームにわたるスプリント ワークロードの最適化
既存のソフトウェア開発プロセスの評価
バリュー・ストリーム・マップを使用して、既存のプロセスや技術を調べるのに役立ちます。
ここでは、以下を行います。
- バリュー・ストリーム・マップ（VSM）について学ぶ
- VSMを使用して、リリースプロセスの改善が必要な場所の感覚をつかむ
- VSMが、現在のDevOpsプラクティスを議論するための良い出発点となることを理解する
Introduction
あなたはリリースプロセスを改善したいですか？
それとも、リリースの頻度を増やしたいと思っているかもしれません。
あるいは、ソフトウェアの品質を向上させたいと思っているかもしれません。
手動プロセスを廃止して、より自動化されたアプローチに移行したいと思っているかもしれません。
いずれの目標であっても、Azure DevOps はお役に立てるでしょう。
学習目的
この章では、以下のことを学びます。
- バリュー・ストリーム・マップ（VSM）について学びます。
- VSMを使用して、リリースプロセスの改善が必要な場所の感覚をつかむ
- VSMが、現在のDevOpsプラクティスを議論するための良い出発点となることを理解する
開発チームの紹介
DevOpsには、チームがコラボレーションしてプロセスを改善するための多くの機能とツールがあります。
DevOpsの旅は、リリースプロセスを改善する必要があることを発見した、架空のソフトウェアチームのメンバーの紹介から始めます。
Tailspin Toys（略してTailspin）は、ビデオゲーム会社である。Tailspinは、ゲームサーバーとウェブサイトをオンプレミスのデータセンターでホストしています。
同社は、新しいレースゲームのリリースを祝ったばかりです。また、スペースゲームと呼ばれるスペースシューティングゲームも近日中にリリースされる予定です。
あなたが担当するチームは、新しいゲームタイトルをサポートするためのウェブサイトを構築します。
これらのウェブサイトでは、ゲームに関する情報や入手方法、トップスコアを表示するリーダーボードなどを提供します。
各ウェブサイトはゲームのリリースと同じ日に公開しなければならないため、チーム間の調整が必要となり、ウェブチームには余分なプレッシャーがかかります。
Space Gameのウェブサイトは、C#で書かれた.NET Coreアプリであり、Linux上にデプロイされています。
ウェブサイトはまだ完成していませんが、現在は以下のようになっています。
そして、リーダーボードはこんな感じです。
モード別、またはゲームマップ別にリーダーボードをフィルタリングすることができます。また、プレイヤーの名前を選択してプロフィールやゲームの実績を見ることもできます。
注意
ゲームもサイトもまだ完成していませんが、今のうちにサイトをチェックしておくことで、ゲームの仕組みを知ることができます。
次にチームメンバーを紹介します。
アンディは子供の頃からコンピュータを使って仕事をしてきた開発主任です。
彼は余暇に個人的なコーディングプロジェクトに取り組むことを楽しんでいます。
アンディは、もっと暇な時間があればいいのにといつも思っています。
アミタは品質保証部(QA)にいます。
彼女は落ち着いていて、気性の荒い開発者を助けてくれます。
彼女は整理整頓と優先順位の設定が得意で、エッジケースを見つけるために生きています。
ティムはオペレーション部に所属しています。
彼は実用的な解決策を好み、非常に用心深い性格です。（一部の人は「被害妄想」という言葉を使うかもしれないが）。
アーウィンはプロダクトマネージャーです。
彼は何十年もゲーム業界にいます。
アーウィンは開発チームに対して友好的に振る舞っていますが、彼が人よりもタイトなスケジュールを好むことは誰もが知っています。
アーウィンは比較的固定観念を持っているが、チームがより少ない労力でより早くゲームを市場に投入する、そのため役立つ情報であれば、どのようなことにも興味を持っています。
マーラは新人。
彼女は開発者としてTailspinに入社したばかりで、アンディの部下です。
彼女がTailspinに入社したのは、ゲームが好きで、小さな会社ならイノベーションの機会がたくさんあると思ったからです。
彼女はDevOpsの大ファンです。
おはようございます（朝のミーティング）
チームのプロダクトマネージャーであるアーウィン氏が皆を会議に呼び出し、不機嫌そうにしています。
レースゲームのリーダーボードは、いくつかの新機能を追加して更新されたばかりで、彼は地元のゲームグループでそれを披露しました。
プレイヤーの反応は、控えめに言ってもがっかりしたものでした。
彼はトップの問題点のリストを読み上げます。
- いくつかの機能が一部のゲームモードでのみ正常に動作する
- プレイヤー数が少ない場合でも、リーダーボードの更新に時間がかかりすぎる
- プレイヤーごとの複数のスコアが複数のプレイヤーとして表示される
- 新しいランキング機能は間違った結果を表示する
- 特定の日付・ゲームセッションなどに応じたスコアをグループ化する方法がない
- 新しいリリースの制作に数ヶ月かかった（しかも壊れている）
- 彼は「これらの問題が修正されるまでどのくらいかかるのか」と要求しています
アンディは考える： そのコードを書くのに1か月かかるのは間違いない。
アミタは思う： これをテストするのに少なくとも一週間はかかるし、アンディが終わるまでは始められないし、彼はいつも新しいコードをこっそり入れたがる。
ティムは考える： 環境をセットアップして本番環境にデプロイするには少なくとも一週間はかかるだろう。
アミタが完成するまでは始められないし、彼女は何かをリリース候補と呼ぶことを決して快く思っていない。
マーラは不思議に思う： この仕事を受けたのは間違いだったのだろうか？
アンディはチームメイトの様子を見回して、「また連絡します」と言った。
チームのリリースプロセス
DevOpsの実践を設定するための最初のステップは、現在のプロセスを評価することです。
以下に示すこれらのことを分析することを意味します。
- デプロイメントパッケージやNuGetなどの既存の成果物（artifacts）およびコンテナリポジトリ
- 既存のテスト管理ツール
- 既存の作業管理ツール
- 移行と統合戦略の推奨
それをTailspinチームと一緒にやってみて、DevOpsがどのように役立つかを見てみましょう。
プロダクトマネージャーのアーウィンが去った後、アミタは言った。
「助けが必要だ。
いつ修正が行われるのかはわからないが、もうすぐだということはわかっています。
私たちは迅速な完了のために集められたわけではありません。
それに、新しいSpace Gameのウェブサイトは、この混乱が解決されるまで停止しなければならないでしょう。
- そして、そのゲームはすぐに復帰する必要がある」
アンディはマーラに話しかける。「これからの最初の数週間の間に、あなたに行なってもらうことはたくさんあります。」
マーラは応答した。「承知しました。それでは、このゲームはどのようにして開発環境から本番環境に移るのか、作業の進め方を説明していただけますか？」
アンディは言った。「それは素晴らしい質問だ。簡単に答えを出すことができないもしれませんが、まずやってみましょう」
チームはコーヒーショップに行き、リラックスして非公式な議論をすることにしました。
彼らはなぜそんなに多くの問題を抱えているのかを一緒に把握しようとします。
コーヒーを飲みながら、マーラは話を聞き、メモを取ろうとします。
情報が多く、整理されていない。
チームについての彼女の全体的な考えは次のとおりです。
- 彼らはウォーターフォールのアプローチを使用しています。
管理者は優先順位を設定します。
開発者がコードを書き、ビルドを品質管理部(QA)に渡す。
QAはテストを行い、その後、デプロイのためにオペレーション部(ops)に引き継ぐ。 - ウォーターフォールは小規模なチームでも受け入れられるかもしれませんが、ここでは目標が常に明確ではなく、頻繁に変更されるようです。
- テストはプロセスの後半まで遅れる。
つまり、バグを修正したり変更を加えたりするのが難しく、コストがかかるということです。 - 「完了(done)」とは何を意味するのか、明確な定義がない。
各チームメンバーが独自のアイデアを持っている。
全員が合意した全体的なビジネス目標がない。 - 一部のコードが集中管理されたバージョン管理システムにある。 ]
多くのツールやスクリプトがネットワーク上のファイル共有にしか存在しない - 手動のプロセスが多い
- コミュニケーションは行き当たりばったりで、電子メール、Word文書、スプレッドシートに依存している。
- フィードバックも頻繁ではなく、一貫性がありません。
- プラス面では、チームは仲が良いようで、物事をより良くしたいと思っています。
彼女がノートの彼女の山を見るとき、Maraは彼女がすべてのこの情報を整理する必要があることを知っています。
整理することで、プロセスを評価しやすくなります。
彼女は、DevOpsアプローチがチームの問題の多くを解決すると確信していますが、チームに自分のケースを提示する方法が必要です。
DevOpsの実践は、多くの場合、既存のプロセスを理解することから始まります。
そこから、何がうまくいっているのか、何がうまくいっていないのかを評価し、まず何を修正すべきかに焦点を当てることができます。
コーヒーショップでタブレットでメモを取るマーラ
マーラは「みなさんは バリューストリームマッピング のエクササイズを行ったことがありますか？」と尋ねました。
アンディは目を丸くし、アミタはため息をつき、ティムは「我々にはこれ以上の事務作業は必要ないよ」と言いました。
マーラは言った「わかりました。 私に任せてください。」
新人に任せることができてよかった･･･とみんな仕事に戻りました。
バリュー・ストリーム・マップでプロセスの効率性を評価
バリューストリームマップ（VSM）を作成することで、現在のリリースサイクルプロセスを分析できます。
VSMの目的は、プロセスのどこでチームが価値を生み出し、どこで無駄があるのかを視覚的に示すことです。
もちろん、目標は、 無駄を最小限に抑えて最大の価値を顧客に提供するプロセスに到達すること です。
VSMを使用することで、価値を生まない部分や、製品の価値を下げている部分を特定することができます。
Tailspinがどのように評価されているか見てみましょう。
チームに加わったばかりのマーラは、既存のプロセスを理解するためにVSMを作成しようとしています。
VSMを使えば、彼女はチームがDevOpsの成熟度モデルの中でどこに当てはまるかを知ることができます。
成熟度の高いチームは、成熟度の低いチームに比べて、より速く、より自信を持って、より少ないバグでリリースするのが一般的です。
マーラは、自分がまだすべてを理解していないことを知っています。
そこで彼女は、会議室のホワイトボードにラフにVSMを作成します。
いくつかのギャップや未回答の質問があるかもしれませんが、それは大丈夫です。
それがスタート地点です。
彼女はできる限りのことができたら、それをチームと共有します。
VSMは全員に共通の出発点を与え、Tailspinのウェブサイトの開発と公開方法を改善するための最初のステップを特定するためのものです。
彼女が作成したマップを見てみましょう。
現在のプロセスを理解する
マーラは会議室にチームを集めてVSMをみせました。
マーラ: VSMは、プロセスのどこが顧客にとって価値のあるもので、どこが価値を生み出さずに時間を浪費しているかを測定するのに役立ちます。
私たちのマップは、左上のソフトウェアの機能仕様から始まります。
ここでは、現在のリリースサイクルを通じて、その機能がどのように移動するかを見るために、1つの機能だけを追っていきます。
目を丸くする人もいますが、マーラは続けます。
開発プロセス
新しい機能の作成は現在、ソースコントロールの
でラベルを作成することから始まります。
ラベルを作成できる人は1人で、それがアンディです。
私たちは電子メールでラベルを要求します。
私たちは集中型のバージョン管理システムを使用しているので、アンディは既存のコードがすべてチェックインされて安定するまで待ってからラベルを作成します。
ラベルが作成されると、作業開始のメールが届きます。
このプロセスは最大で3日かかり、顧客にとっては何の価値もありません。
顧客にとって価値のないものは、できるだけ時間をかけないほうがいい。
に必要なすべてのファイルにアクセスできるようになれば、機能をコーディングするのに1人で4日ほどかかります。
ソースコントロールにアクセスするためには、企業のネットワーク上にいなければなりません。
この時間は顧客にとって価値があります。
彼らはこの機能を欲しがっています。
テストプロセス
安定したビルドができたと判断したら、スプレッドシートを更新して、テストの準備ができたビルドがあることと
の場所をアミタに伝えます。
通知を受けるまでに2日かかります。
アミタは手動でビルドをテストしています。
このプロセスはコードベースが大きくなるにつれて長くなります。
今のところ、3日としましょう。
彼女はその後、アンディにバグレポートをメールで送ります。
テストは付加価値を高めるものではありませんが、必要なものです。
アンディはその後、バグをトリアージ(対応する順序および対応しないなどの決定)して
に作業を割り当てるために時間を取らなければなりません。
アンディが問題を理解して適切な開発者に届けるまでには、さらに3日かかることもあります。
運用プロセス
アミタがビルドを承認すると、彼女はそれをティムに渡します。
ティムは、より多くのテストのために、このビルドをプリプロダクションサーバにデプロイする必要があります。
多くの場合、プリプロダクションサーバは、ウェブサイトを実行するために必要な最新のパッチやアップデートと同期していません。
ティムは、プリプロダクションにデプロイしてテストを実行するのに約2日かかります。
繰り返しになりますが、プリプロダクションにデプロイしても付加価値はありませんが、
は必要です。
ビルドの準備ができたら、デプロイする前にリーダーシップがリリースを承認する必要があります。
これは会議で行われます。
リーダーシップに会議を開いてもらい、リリースを確認してもらうのに4日かかっています。
最終的に、ティムが機能をデプロイし、その機能はVSMの右上に表示されている顧客に届きます。
本番サーバーの構成がプレプロダクションと同期していないためにドリフトしている場合、ティムはまずそれを更新する必要があります。
顧客価値のメトリクスを計算する
ここで、主要なパフォーマンス指標を見て、どのように測定しているかを確認してみましょう。
総リードタイムとは、機能が顧客に届くまでにかかる時間のことです。プロセスタイムとは、顧客にとって価値のある機能に費やされた時間です。アクティビティ比率は、プロセス時間を総リードタイムで割ったものです。
Activity ratio = Process time / Total lead time
これが効率です。効率を100倍にするとパーセンテージになります。その結果は0%よりも大きく、通常は100%よりも小さくなります。パーセンテージが高いほど効率が高いことを示しています。
私たちの数字を代入すると、次のようになります。
Activity ratio = 5 days / 22 days = .23
100％を乗算すると23％になります。
ご覧の通り、まだまだ改善の余地があります。
そして、1つの機能を開発するのに22日かかるのは長すぎます。
ティム：では、これがどのように私たちを役立つのでしょうか？
これからどうすればいいのか？
マーラ: 現在の状況を把握することで、無駄な部分をピンポイントで把握することができます。
お客様にとって価値のない時間を最小限にしたいと思っています。
DevOpsのアプローチを採用することで、効率性を大幅に向上させることができると思います。
一つには、これらのステップの多くを自動化することができ、時間を確実に削減することができます。
現在のプロセスを捨てろと言っているわけではありませんが、現在のプロセスを中断することなく、少しずつ効率的なプロセスを目指していくことができると思います。
では、改善できる部分をいくつか挙げてみましょう。
アンディ：最初から始めたほうがいいかもしれませんね。
新しい機能を開始するために、コードにラベルを付けるのに時間がかかります。
私は開発者のところを歩き回って、彼らが持っているものをチェックするように頼まなければならないので、ビルドしてテストすることができます。
どうやってスピードを上げるかを考えてくれれば、私の注目を集めることができるでしょう。
あと、気がついたのですが、ビルド自体のための時間がないんですよね。
今は半日かかっています。その時間が改善されるといいですね。
アミタ:あと、開発者は常にスプレッドシートを更新して、テストが必要となる新しいビルドがあることを通知してくれるわけではありません。
その部分を確実に完了させる方法があれば、時間の節約になりますね。
マーラ: 素晴らしいですね。
DevOpsはこれらの懸念事項を解決してくれると思います。
アンディ: しかし、今はこれらのプロセスを変更している時間はありません。
アーウィンの話を聞いたでしょ。今は危機的状況なんだよ。
マーラ: 承知しています。 今のところは、いつものようにしましょう。
でも、プロセスの中での自分の役割を考えて、どうすれば改善できるかをみんなで考えましょう。
今のプロセスと並行して、小さな変更を始めることができます。
そうすれば、今あるものを壊さずにDevOpsが私たちを助けてくれるかどうかがわかるだろう。
私はこのマップとパフォーマンスのメトリクスを保管しておこうと思います。
最終的にAzure DevOpsのプラクティスを採用することになったら、数値を見直すことができる。
もしかしたら、どこかのタイミングでVSMを更新できるかもしれない。
まとめ
ご覧のように、マーラと彼女のチームは多くの課題に直面しています。
リリースは最終的には行われますが、マーラはリリースをもっと頻繁に、効率的に行うことができると感じています。
マーラは、少なくとも DevOpsアプローチをテストする価値があるとチームに納得させたいと考えています。
おそらく、彼らはSpace Gameのウェブサイトの作業を終えるときに、いくつかのDevOpsのプラクティスを適用することができるでしょう。
DevOpsとは何ですか？
この時点では、まだDevOpsを定義していません。
それについては次の章で説明します。
しかし、今のところ、DevOpsとは、人、プロセス、製品を結びつけ、ソフトウェア配信を自動化してユーザーに継続的な価値を提供するものだと考えてください。
Azure DevOpsは、DevOpsのライフサイクル全体にまたがる一連のサービスです。
Azure DevOps は、計画から始まり、デプロイメントとモニタリングまでを一貫して行います。
すでにいくつかのパーツが用意されている場合は、どのサービスを使用するかを選択することができます。
Azure DevOpsは、Jenkinsなどの多くのツールと統合されています。
Azure DevOpsについては、今後の章でさらに深く掘り下げていきます。これらのリソースもチェックしてみてください。
Azure DevOpsへのツール移行・統合の一般的な推奨事項
既存のすべてのアーティファクトとツールを分析することが、DevOps戦略を設計するための最初のステップであることはお分かりいただけたと思います。
それができたら、Azure DevOps を使用している場合に使用できる移行および統合戦略を策定するためのいくつかの推奨事項をご紹介します。
認証とアクセス戦略の設計
Azure DevOps Servicesは、エンタープライズグレードの認証を使用しています。
Microsoft アカウントまたは Azure Active Directory (Azure AD) のいずれかを使用して、データの保護と安全性を確保することができます。
Visual StudioやVisual Studio Codeなどの多くのクライアントアプリケーションは、MicrosoftアカウントまたはAzure ADのいずれかによる認証をネイティブにサポートしています。
また、Team Explorer Everywhere プラグインをインストールしている場合、Eclipseも同様にサポートしています。
Azure DevOps Servicesと直接統合するためにMicrosoft以外のツールが必要で、ツールが直接認証のためにMicrosoftアカウントまたはAzure ADアカウントをサポートしていない場合でも、パーソナルアクセストークンを設定することでそれらを使用することができます。
このトークンはGitのクレデンシャルマネージャーを使って設定することもできますし、手動で作成することもできます。
個人用アクセストークンは、コマンドラインツールやビルドパイプラインのツールやタスク、REST ベースの API を呼び出す際にも便利です。アクセスが不要になったら、パーソナルアクセストークンを取り消すことができます。
Azure DevOpsには、デフォルトのセキュリティグループがあらかじめ設定されています。
デフォルトの権限はデフォルトのセキュリティグループに割り当てられています。
しかし、組織レベル、コレクションレベル、プロジェクトやオブジェクトレベルでのアクセスを設定することもできます。
Azure DevOps の組織設定では、アプリのアクセス ポリシーを設定できます。
セキュリティポリシーに基づいて、代替の認証方法を許可したり、サードパーティのアプリケーションがOAuth経由でアクセスできるようにしたり、一部のプロジェクトへの匿名アクセスを許可したりすることができます。
さらに厳しく制御するには、Azure DevOps への条件付きアクセスを設定することができます。
これは、認証にAzure Active Directoryを使用する際にリソースの安全性を確保するのに役立つ簡単な方法を提供します。
多要素認証などの条件付きアクセスポリシーは、資格情報が漏洩するリスクを最小限に抑えるのに役立ちます。
条件付きアクセスポリシーの一部として、セキュリティグループのメンバーシップ、特定の場所やネットワーク ID、特定のオペレーティングシステム、管理対象のデバイス、またはその他の条件を要求することができます。
アーティファクト・リポジトリの移行と統合
Azure DevOpsを使用している場合、既存のアーティファクトリポジトリを現在の場所で作業を続けることができますが、移行することにはメリットがあります。
NuGetについては、Azure DevOps ServicesがサービスとしてホストされたNuGetフィードを提供しています。
このサービスを利用することで、ファイル共有やローカルでホストされているNuGet.Serverのインスタンスなど、オンプレミスのリソースへの依存をなくすことができることが多いです。
また、認証済みのNuGetフィードをサポートしている継続的インテグレーションシステムであれば、どのような場合でもフィードを利用することができます。
ライセンス戦略の設計
Azure DevOpsには、さまざまな状況に合わせて設計されたさまざまなライセンシングポリシーがあります。概要を簡単に知るには、Azure DevOps の料金を参照して、利用可能なものを確認してください。
また、無料と有料の両方の拡張機能が多数あり、その多くはサードパーティ製アプリケーションを統合するために使用します。
現在の構成に応じて、グループベースのライセンスの導入を決定することもできます。
これにより、Azure DevOps でのライセンス管理が容易になります。
ただし、この変更を計画している場合は、Group-Based Licensing への移行により、ユーザーが現在割り当てられているライセンスを一時的に失うような状況を避けることが重要です。
Azure DevOps ライセンスに加えて、必要なサードパーティ製ツールに適切なライセンスがあることを確認する必要があります。
また、含まれているオープンソースのツールには、それらの使用方法と互換性のあるライセンスが含まれていることを確認する必要があります。
ソース管理の移行と統合
アーティファクトと同様に、Azure Reposを使ってソース管理をAzure DevOpsに移行することを検討してみてはいかがでしょうか。
しかし、集中型のバージョン管理システムからGitのような分散型システムにチームを移行するには、新しいコマンドを覚えるだけでは不十分です。
Gitへの移行を成功させるには、ファイル履歴やブランチの扱い方の違いを理解する必要があります。
Azure DevOpsチームは、以下のプロセスを推奨しています。
- 使用しているツールやプロセスを評価する。
- Git のブランチ戦略を選択する。
- 履歴をどのように移行するかを決める。
- 古いバージョン管理システムを維持する。
- ソース管理からバイナリや実行ファイルを削除する。
- チームにGitの概念と実践方法を教える。
- 実際にGitへの移行を行う。
作業管理ツールの移行と統合
他の作業管理ツールからAzure DevOpsへの移行には、かなりの計画が必要です。
ほとんどの作業管理ツールは、エンドユーザーが高度に設定できるようになっています。
つまり、これ以上の設定をしなくても移行を実行してくれるツールがない場合があるということです。
その一例が Jira です。
Visual Studio Marketplaceでは、SolidifyがJiraからAzure DevOpsへの移行ツールを提供しています。
これは2つのフェーズで移行を行います。Jira の課題をファイルにエクスポートし、そのファイルを Azure DevOps にインポートします。
移行コードを自分で書いてみようと思ったら、以下のブログ記事にサンプルコードがありますので、始めるのに役立つかもしれません。
Migrate Your Project From Jira to Azure DevOps
テストツールの移行と統合
Azure Test Plans: スプリントやマイルストーンの手動テストを追跡する際に利用できます。利用すると「テストがいつ完了したか」を追跡できます。
Apache JMeter: Javaで書かれたオープンソースのソフトウェアで、機能動作をロードテストしてパフォーマンスを測定するように設計されています。
Pester:PowerShellコードのテストを自動化するために使用できるツールです。
SoapUI SOAPとRESTテストのためのもう一つのテストフレームワークです。
続きの記事は
なお、この記事の続きは「AZ-400学習リソースを共有します 1-2 DevOps プラクティスを発展させる – Azure DevOpsをはじめよう」で公開しています。
