演習 - ビルド バッジを追加する
チーム メンバーがビルドの状態を把握することが重要です。 ビルドの状態をすばやく確認する簡単な方法は、GitHub の README.md ファイルにビルド バッジを追加することです。 チームの様子を見て、それがどのように行われたかを確かめましょう。
Andy は自分のデスクにいて、メールの処理を進めています。 Space Game Web サイトのビルド状態に関連する 3 番目のメールに回答しています。
アンディ: ステータス メッセージを自動化するには、何らかの方法が必要です。 パイプラインは利用中なので、どこかに状態を配置できる必要があります。 どうすればそれが可能かは、おそらく Mara が知っています。
Andy は、休憩室で Amita と話している Mara を見つけます。
アンディ: こんにちは、Amita. ちょっと Mara を借りてもいいかな。
Amita: とにかく会議に行かなければなりません。 どうぞ。
マラ: こんにちはアンディ。 なんでしょうか。
アンディ: Azure Pipelines を使用してビルド パイプラインに加えた変更が本当に好きで、Git は優れたバージョン管理システムです。 私が知りたかったのは、ビルドの状態を皆に知らせる方法があるか、ということです。
マラ: はい。実際には。 ビルド バッジを利用できます。
ビルド バッジとは何か
バッジは Microsoft Azure Pipelines の一部です。 これには SVG イメージを追加するために使用できるメソッドが用意されていて、GitHub リポジトリでのビルドの状態が示されます。
ほとんどの GitHub リポジトリには 、README.md という名前のファイルが含まれています。これは、プロジェクトに関する重要な詳細とドキュメントを含む Markdown ファイルです。 GitHub では、このファイルがプロジェクトのホーム ページに表示されます。
ビルド バッジの例を次に示します。
この演習では、全員にビルドバッジが表示されるようにします。 ビルド情報が一般に提供されるようになるため、これは個人のプロジェクトには適さないアイデアとなる可能性があります。
ビルド バッジが表示されていることを確認するには、次の操作を行います。
Azure DevOps で、あなたの組織に移動します。
下部にある [ 組織の設定 ] を選択します。
パイプラインで、設定を選択します。
[ バッジへの匿名アクセスを無効にする] をオフにします。
プロジェクトにも同様の変更を加える必要があります。
- プロジェクトに移動します。
- 下隅から [プロジェクトの設定] に移動します。
- パイプライン で 設定 を選択します。
- [ バッジへの匿名アクセスを無効にする] をオフにします。
ビルド バッジを追加する
これまでは、 Space Game プロジェクトに変更を加えるために Git ブランチをローカルに作成しました。 GitHub を通して直接変更を提出することもできます。 このセクションではそれを行って状態バッジを設定します。
Azure DevOps の左側のウィンドウで、[ パイプライン] を選択し、パイプラインを選択します。
右上にある省略記号 (...) を選択し、[ 状態バッジ] を選択します。
[ サンプル マークダウン] で、[ コピー ] ボタンを選択して、マークダウン コードをクリップボードにコピーします。
GitHub で、あなたのプロジェクトに移動します。
main
ブランチにいることを確認します。 [ファイル] 領域で、 README.md ファイルを開きます。[ このファイルの編集] (鉛筆アイコン) を選択して、エディターでファイルを開きます。
ページ最上部に空白行を追加してから、クリップボードの内容を貼り付けます。
[プレビュー] タブを選択して、提案された変更を表示します。
GitHub によって Markdown ファイルがレンダリングされ、ビルド バッジが表示されます。
変更をメインにコミットする
このセクションでは、GitHub 上の main
ブランチに変更をコミットします。
[変更をコミットする] を選びます。
[ コミット メッセージ ] 領域で、コミット メッセージ ("ビルド バッジの追加" など) を指定します。
[ commit directly to the
main
branch]\( ブランチに直接コミット する\) オプションをオンのままにして、[ 変更のコミット ] を選択して、変更をmain
ブランチにコミットします。バッジが README.md ページに表示されます。
このプロセスは、コードを GitHub にマージする、より基本的な方法です。 直接コミットする代わりに、他の人が確認できるよう、自分の変更を含むプル要求を作成した可能性があります。
実際には、次に機能を追加したりバグに対処したりする必要があるときに、
main
ブランチに切り替えて最新の変更を GitHub からプルします。
アンディ: Mara、 main
に直接変更を加えただけです。 あなたが私に教えたフローを使用しなかったのはなぜですか。 あの、機能ブランチを使用する方法です。
マラ: 私たちはそうすることができました。 しかし、README ファイルやその他のドキュメント ファイルだけを変更しようとしているときに、開発者は時折、main
にコミットします。 さらに、変更をマージする前に、あなたと私が一緒に作業内容を検証することが可能でした。
しかし、これは良い指摘です。 望むときは全員がそのまま main
にコミットできる場合は、コード スリップ内の問題を main
ブランチに紛れ込ませている可能性があります。
アンディ: そのことについて、ずっとあなたに話したいと思っていました。
Andy と Mara は、オフィスに戻りながらこの会話を続けています。