演習 - パイプラインを通して変更をプッシュする

• 14 分

このパートでは、動作中のデプロイ スロットを表示します。 Web サイトのホーム ページで、背景色とヒーロー バナーのテキストを変更します。 その後で、変更を GitHub にプッシュし、パイプラインの実行を監視して、変更を確認します。

プロセスをさらに進めるために、変更を元に戻し、ロールフォワードの方法としてのパイプライン実行を監視します。

ヒーロー バナーのテキストを変更する

ここでは、ヒーロー バナーのテキストを変更します。 この変更は、後で App Service にデプロイすると表示されます。

1. Visual Studio Code で、Tailspin.SpaceGame.Web/Views/Home ディレクトリにある Index.cshtml を開きます。

2. ページの上部付近で、次のテキストを探します。

   <p>An example site for learning</p>
   

   ヒント

   Visual Studio Code には、ファイル内のテキストを検索する方法が用意されています。 検索ペインにアクセスするには、横のペインで虫眼鏡アイコンを選択します。

3. 例のテキストを次のテキストに置き換えてから、ファイルを保存します。

   <p>Welcome to the official Space Game site!</p>
   

背景色を変更する

ここでは、ヒーロー バナーの背景色を灰色から緑色に変更します。

1. Visual Studio Code で、Tailspin.SpaceGame.Web/wwwroot/css ディレクトリにある site.scss を開きます。

   重要

   site.css ではなく site.scss を開きます。 "ビルド" のステージで node-sass を実行して、site.scss (Sass ファイル) が site.css (標準の CSS ファイル) に変換されます。

2. ファイルの先頭付近で、次のコードを見つけます。

   .intro {
     height: 350px;
     background-color: #666;
     background-image: url('/images/space-background.svg');
     background-size: 1440px;
     background-position: center top;
     background-repeat: no-repeat;
     background-attachment: fixed;
   

3. コード内で、強調表示されているテキストを次の例に示すように置換します。 そのうえでファイルを保存します。

   .intro {
     height: 350px;
     background-color: green;
     background-image: url('/images/space-background.svg');
     background-size: 1440px;
     background-position: center top;
     background-repeat: no-repeat;
     background-attachment: fixed;
   

パイプラインを通して変更をプッシュする

通常は、ローカルでサイトをビルドして実行し、変更を確認します。 関連する単体テストを実行して、変更によって既存の機能が損なわれないと確認することもできます。

簡潔にするために、ここでは変更をブランチにコミットし、ブランチを GitHub にプッシュして、パイプラインの実行を監視します。

1. Index.cshtml と site.scss をインデックスに追加し、変更をコミットしてから、変更を GitHub にプッシュします。

   git add Tailspin.SpaceGame.Web/Views/Home/Index.cshtml Tailspin.SpaceGame.Web/wwwroot/css/site.scss
   git commit -m "Change text and colors on the home page"
   git push origin blue-green
   

2. Azure Pipelines で、各ステップを通してビルドをトレースします。

3. "ステージング" 環境の production スロットに対応する URL にアクセスします。 このスロットは、前にパイプラインを設定したときに構成した、既定のスロットです。

   デプロイされた Web サイトに、色とテキストの変更が表示されていることがわかります。

   

4. "ステージング" 環境の swap スロットに対応する URL にアクセスします。 その URL の名前には、"-swap.azurewebsites.net" が含まれています。

   色とテキストの変更がない前のバージョンの Web サイトが表示されます。

   

   production スロットと swap スロットをスワップしたため、変更は表示されません。 言い換えれば、ここでは、常に swap スロットにデプロイし、その後、production スロットと swap スロットをスワップします。 このスワップ プロセスにより、production スロットがより新しいデプロイを指し示すようになります。

変更を元に戻します

元に戻したい変更をデプロイしたとします。 この時点で、production スロットと swap スロットをもう一度スワップすることで、変更をロールバックできます。 たとえば、Azure portal から手動でスロットをスワップできます。 または、変更をロールバックするのではなく、パイプラインを通して別の変更をプッシュすることで、ロールフォワードすることもできます。

それが、ここで実行しようとしていることです。 最後のコード変更を元に戻して、パイプラインを通して別の変更をプッシュします。 そのためには、git revert コマンドを使用します。

Git でファイルの履歴からコミットを削除することは、めったにありません。 テキスト エディターでの "元に戻す" 操作とは異なり、git revert コマンドでは、指定された一連のコミットとは基本的に逆の、新しいコミットが作成されます。 これらのコミットを確認するには、最初に git log コマンドを実行して、元に戻すプロセスの間にコミット履歴をトレースします。

1. ターミナルで次の git log コマンドを実行して、コミット履歴を表示します。

   git --no-pager log --oneline
   

   出力は、次のようなコード例のようになります。 出力には、追加のコミットと、異なるコミット ID が表示されます。

   d6130b0 (HEAD -> blue-green, origin/blue-green) Change text and colors on the home page
   ce56955 Swap deployment slots
   0d6a123 Trigger the pipeline
   

   出力で、コミット履歴をトレースします。 最新のコミットが上の方にあります。

2. 次の git revert コマンドを実行して、1 回のコミットの単位で元に戻します。

   git revert --no-edit HEAD
   

   HEAD はブランチの現在の状態だと考えてください。 HEAD は、最新のコミットを指しています。 このコマンドでは、HEAD (最新の) コミットのみを元に戻すように指定しています。

3. git log を再実行して、更新されたコミット履歴を表示します。

   git --no-pager log --oneline
   

   出力の先頭に、前のコミットを元に戻す追加のコミットが表示されます。 次に例を示します。

   e58896a (HEAD -> blue-green) Revert "Change text and colors on the home page"
   d6130b0 (origin/blue-green) Change text and colors on the home page
   ce56955 Swap deployment slots
   0d6a123 Trigger the pipeline
   

元に戻された変更をパイプラインを通してプッシュする

ここでは、元に戻された変更をパイプラインを介してプッシュし、結果を表示します。

1. 次の git push コマンドを実行し、GitHub リポジトリに blue-green ブランチをアップロードします。

   git push origin blue-green
   

2. Azure Pipelines でそのビルドに移動します。 実行中に、ビルドをトレースします。

3. "ステージング" 環境の swap スロットと production スロットに対応する URL にアクセスします。

   この時点で、production スロットは、元の Web サイトである元に戻された変更を指し示します。

   

   swap スロットは前の変更を指し示すようになりました。

   

上出来 チームはこれで、リリースを自動化する手段を手にしました。 ダウンタイムを発生させずに、ユーザーに新機能を届けることができます。

チーム ミーティング

チームは、パイプラインのデモのために集まっています。 今回 Tim は、全員が見ているときにパイプラインを通して変更をプッシュします。 しかし、全員が納得したわけではありません。

Andy: 動作しているデプロイ スロットが見られてよかったです。 しかし、わからないことがあります。 これによって、ダウンタイムなしのデプロイからどのようにメリットを引き出すのですか。 "ステージング" は、私たちのチームと、管理者のためだけのものです。

Tim: 確かに、今現在、多くのメリットは見られません。 しかし、"運用" のステージにブルーグリーン デプロイを適用した場合を想像してください。 "運用" に昇格させる前に、管理者からはまだ、手動で承認を受けることになります。 しかし、新機能をリリースすると、スワップ プロセスによってロールアウトがほぼ瞬時に行われます。 これはユーザーにとってシームレスです。

Andy: OK、これでわかったと思います。 この改善はいいですね。 デプロイ スロットのシステムは設定が容易で、ユーザーにとってのメリットになります。 全員が恩恵を受けます。

Amita: 改善といえば、数週間前に行ったバリュー ストリーム マッピングの演習をもう一度実施しませんか。 どれだけ迅速に新機能をリリースできるか、進行状況を確認できるはずです。

Mara: いいですね。それを次回のチーム ミーティングの議題にしましょう。