练习 - 通过管道推送更改

14 分钟

在此部分中，你将查看部署槽位的实际运行情况。在网站的主页上，更改主横幅上的背景色和文本。然后将更改推送到 GitHub，观察管道运行，并验证更改。

若要进一步练习该过程，随后请还原所作更改，以前滚的方式观察管道运行情况。

更改主图横幅上的文本

在这里，更改英雄横幅上的文本。稍后，你将在部署到应用服务时看到更改。

在 Visual Studio Code 的 Tailspin.SpaceGame.Web/Views/Home 目录中，打开 Index.cshtml。
在页面顶部附近查找此文本：
```
<p>An example site for learning</p>
```
小窍门

Visual Studio Code 提供了一种在文件中搜索文本的方法。若要访问搜索窗格，请选择侧窗格中放大镜图标。
将示例文本替换为以下文本，然后保存文件。
```
<p>Welcome to the official Space Game site!</p>
```

更改背景颜色

在这里，你将英雄横幅的背景色从灰色更改为绿色。

在 Visual Studio Code 的 Tailspin.SpaceGame.Web/wwwroot/css 目录中，打开 site.scss。

重要

打开 site.scss，而不是 site.css。生成阶段运行node-sass以将 site.scss（Sass 文件）转换为site.css（标准 CSS 文件）。

在文件顶部附近找到以下代码：

.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;

在代码中，替换突出显示的文本，如以下示例所示。然后保存文件。

.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，然后观察管道运行情况。

将 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

从 Azure Pipelines 中，跟踪生成的每个步骤。
转到与过渡环境的生产槽位对应的 URL。此槽是前面设置管道时配置的默认槽。

你会看到已部署的网站显示颜色和文本更改。
转到与过渡环境的交换槽位对应的 URL。 URL 在其名称中包含“-swap.azurewebsites.net”。

你会看到网站的早期版本，没有颜色和文本更改。

你看不到任何更改，是因为你交换了生产槽和备用槽。换句话说，此处始终部署到交换槽位，然后将生产槽位和交换槽位进行交换。交换过程可确保生产槽位指向更新的部署。

还原更改

假设你部署了一项更改，但想要将其还原。此时，可再次交换生产槽位和交换槽位来回滚更改。例如，可以通过 Azure 门户手动交换槽位。也可通过管道推送另一项更改来将更改前滚，而不是将更改回滚。

这是你将在此处执行的操作。你将还原最新的代码更改，并通过管道推送另一项更改。为此，请使用 git revert 命令。

在 Git 中，你很少会移除文件历史中的提交。不同于文本编辑器中的“撤销”操作，git revert 命令会创建一个新的提交，该提交实际上是指定提交集的反向。要查看提交记录，请首先运行git log命令以追溯还原过程中的提交历史记录。

在终端中 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
```
在输出中，跟踪提交历史记录。最新的提交位于顶部。
运行以下 git revert 命令来还原一个提交。
```
git revert --no-edit HEAD
```
将 HEAD 视为分支的当前状态。 HEAD 指的是最新的提交。此命令指定仅还原 HEAD 提交（即最新提交）。

再次运行 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

通过管道推送已还原的更改

在这里，请通过管道推送已还原的更改并查看结果。

git push运行以下命令，将blue-green分支上传到 GitHub 存储库。
```
git push origin blue-green
```
在 Azure Pipelines 中，转到生成。在生成运行时对其进行跟踪。
转到过渡环境的交换槽位和生产槽位所对应的 URL。

生产槽位现在指向已还原的更改（即原始网站）。

交换槽位现在指向上一项更改。

出色的工作！团队现在有办法自动化软件发布。他们可以在不造成停机的情况下向用户提供新功能。

团队会议

团队聚在一起来演示管道。这一次，Tim 通过管道来推送更改，其他人都在观看。但并不是每个人都相信。

Andy：看着部署槽位实际运行太棒了。我不明白。我们如何能从这里的零停机时间部署中受益？过渡槽位仅适用于我们的团队和管理层。

提姆： 事实上，我们现在不会看到太大的好处。但想象一下，当我们将蓝绿部署应用到生产阶段时。在提升到生产阶段之前，我们仍然需要来自管理层的手动批准。但是，当我们发布新功能时，交换过程将使推出几乎瞬间完成。这对我们的用户来说就是无缝操作。

安迪： 好吧，我想我现在明白了。我喜欢这种改进。部署槽位系统易于设置，这将有利于我们的用户。每个人都赢了

Amita： 谈到改进，我们要不要重新审视我们前几周做的价值流映射练习？我敢打赌，我们会看到在发布新功能速度上的进步。

玛拉： 很好，让我们把这放在下一个团队会议的议程上。