如何创建AWS持续部署管道Cont’d
我们将通过审查阶段、更有效地使用Maven缓存和向管道添加通知来增强管道。
1.导言
在我们之前的博客中，我们一步一步地使用AWS服务创建了一个持续的部署管道。建议在继续这个博客之前先阅读那个博客。我们将通过手动审查阶段来增强管道。这将允许我们在部署新版本到弹性豆茎之前有一个额外的确认步骤。这只有在您需要这个额外的确认时才是必要的。当您对管道中的前面步骤足够自信时，自动部署会更容易、更快，而不需要任何手动干预。
我们还将仔细研究构建时间。AWS构建在Docker容器中运行。这意味着每次构建，所有的Maven依赖项都将被下载。这可能会在应用程序增长时导致大量时间。我们将看看如何通过S3桶使用Maven缓存。
最后，我们将在构建过程中的某些阶段创建通知。这是一个很好的功能，它允许我们收到某些事件的通知，而不需要自己持续监控管道的状态。
本博客中使用的源代码可以在GitHub上找到。
2.增加审查阶段
在本节中，我们将在将应用程序的新版本部署到弹性豆茎之前，在管道中添加一个手动审查步骤。在我们的上一篇文章中，我们已经创建了一个My AW SCD Planet管道，它检查GitHub存储库中的源代码，使用Code Build构建应用程序，并将应用程序自动部署到弹性豆茎。
导航到Code Pipeline服务并选择My AW SCD Planet管道。单击右上角的编辑按钮。
单击生成和部署阶段之间的添加阶段按钮。
给舞台一个有意义的名字，我们选择Manual_Review并单击添加舞台按钮。注意，舞台名称不能包含空格。
已添加阶段。单击新创建的Manual_Review阶段中的添加操作组按钮。
填写操作名称和操作提供程序。可使用的操作提供程序列表很大，选择手动审批，然后单击完成按钮。
为了最终确定所有内容，请单击Manual_Review阶段的完成按钮和右上角的橙色保存按钮。显示一个确认窗口，我们需要在其中再次确认管道的更改。
让我们看看这是如何工作的！在Hello Controller中更改文本。
也改变相应的测试。
验证我们的更改是否可以成功构建。
如果构建成功，提交并将更改推送到GitHub。管道开始运行，但这次不会自动将更改部署到弹性豆茎。相反，管道在审查阶段停止。
单击审核按钮显示审核批准屏幕。单击批准按钮，管道将继续并将更改部署到弹性豆茎。
3. Maven缓存
在管道的设置过程中，我们注意到Maven依赖项随每个构建一起下载。这并不奇怪，因为构建在Docker容器中运行，并且没有注意到以前的构建。在本节中，我们将仔细研究这个问题，并为此提供一个解决方案。
让我们仔细看看构建日志。导航到Code Build并单击最新的成功构建运行。
在生成日志部分，单击查看整个日志链接。
打开一个新的浏览器窗口，导航到Cloud Watch，在那里我们可以搜索和显示日志事件。单击加载更多链接。
当我们仔细查看日志时，我们注意到Maven依赖项在每次构建时都被下载。这占用了不必要的构建时间。它对我们正在使用的小应用程序影响不大，但是当使用现实生活中的应用程序时，这会消耗大量的时间。
为了加快一点速度，我们将配置构建，以便它将使用Maven缓存，就像在我们的本地开发机器上一样。
再次导航到生成项目，然后单击右上角的编辑按钮，选择Build spec。
将缓存部分添加到配置Build spec。
最后，单击Update build spec按钮。
首先，如果您还没有S3存储桶，我们需要创建一个S3存储桶。导航到S3服务，然后单击右上角的创建存储桶按钮。我们只需输入一个名称，我们选择my Developer Planet**-maven-cache**，然后单击页面底部的创建存储桶按钮。
再次导航到构建项目，单击右上角的编辑按钮并选择工件。选择Amazon S3作为缓存类型，选择code pipeline S3桶作为缓存桶，将缓存路径前缀设置为/cache/archives/并单击更新工件按钮。
我们遇到了错误无效缓存：位置必须是一个有效的S3桶，然后是斜杠和前缀，当一步执行时。我们通过首先将缓存路径前缀留空来编辑工件，然后在第二步中只编辑缓存路径前缀来解决这个问题。
单击开始构建按钮。第一次，工件将被再次下载，但这次是在S3桶中。第二次运行它，这次构建使用配置的Maven缓存。
让我们比较构建阶段。初始构建的构建阶段。
使用Maven缓存进行构建的构建阶段。
我们注意到，对于我们正在使用的小应用程序，DOWNLOAD_SOURCE步骤增加了一点，BUILD步骤减少了很多。总的来说，我们的小应用程序的构建时间增加了10秒。
4.添加通知
当有人推送到主分支时，我们创建的管道会自动构建，在手动批准后，应用程序将部署到弹性豆茎。我们需要自己监控管道，以便注意管道正在等待批准或管道是否失败。为了解决这个问题，我们可以向管道添加通知。
导航到管道，单击右上角的通知按钮，然后选择创建通知规则。
给规则一个名称，我们选择My AW SCD Planet**-管道-规则**，选择基本作为细节类型（这将在通知中提供最少的信息，并且被认为比完整更安全**），选择您想要接收通知的触发器。我们选择失败的管道、成功的管道和何时需要**手动批准。
接下来，我们需要创建一个发送通知的目标。单击创建目标按钮。我们选择SNS主题作为目标类型，因为我们想以通知的形式发送邮件，并给主题一个名称。单击创建按钮。
目标将自动填写，单击创建通知规则表单中的提交按钮后，通知规则将被创建并激活。
为了接收邮件通知，我们需要订阅我们创建的主题。我们需要导航到简单通知服务的主页。在导航栏中，我们可以导航到主题，在那里我们可以找到我们刚刚创建的主题。但是，我们会导航到订阅部分，因为我们需要通过单击创建订阅按钮来创建订阅。
选择我们之前创建的主题作为主题ARN。选择协议。有几种可用的协议，但我们将使用电子邮件协议。最后，用您想要接收通知的邮件地址填写端点。单击创建订阅按钮以完成订阅创建。
到目前为止，您将在配置的邮件地址收到一封邮件，您需要在该地址确认订阅该主题。
让我们看看这是如何工作的。我们再次更改Hello Controller中的Hello消息。
不要忘记改变相应的测试也。
使用mvn干净安装检查本地版本，成功构建后，提交并将更改推送到GitHub。管道开始构建，在审查阶段，我们收到一封包含JSON消息的邮件，其中包含管道正在等待审查的消息。我们导航到管道并批准审查。部署阶段结束后，我们再次收到一封包含JSON消息的邮件，其中包含管道成功结束的消息。
与其为了验证管道更改而进行更改，还可以单击管道右上角的发布更改按钮。这将使用新配置的更改重新运行管道。
六.结论
我们对之前创建的管道进行了一些增强，以探索使用的AWS服务的一些额外功能。有很多可能性，探索这些可能性并尝试它们是一个好习惯。其中一些可能对您有用，可以立即应用到您的管道中。
主题：
aws， code build， code pipeline，弹性豆茎， java，弹簧引导
