设计管道和版本控制策略
开始发布可重用 Bicep 代码时，可能会使用手动方法。 你可以很容易地确定需要发布哪个 Bicep 文件，并且可能需要手动递增版本号。
自动执行发布过程时，需要考虑如何自动执行这些步骤。 在本单元中，你会了解如何采用版本控制系统来传达你对代码所做的更改。 你还将了解如何将管道范围限定为仅发布所需的代码。
版本号
在以前的 Microsoft Learn 训练模块中，你了解了对模板规格和 Bicep 模块进行版本控制的重要性。 可以从许多不同的版本控制方法中进行选择。 在许多情况下，使用多部分版本控制系统是一种很好的做法。 多部分版本控制系统由主版本、次要版本和修订号组成，类似于以下示例：
在前面的示例中，主版本为 1，次要版本为 4，修订号为 106。
版本号不同部分的更改传达了有关代码更改类型的重要信息：
每当进行中断性变更时，都应递增主版本号。 例如，假设你添加了一个新的必需参数，或者从 Bicep 文件中删除了一个参数。 这些便是中断性变更的示例，因为 Bicep 要求在部署时指定必需的参数，并且不允许为不存在的参数设置值。 因此，你需要更新主版本号。
每当向代码添加新内容，但并非中断性变更时，应递增次要版本号。 例如，假设你添加了一个带有默认值的新可选参数。 可选参数不是中断性变更，因此应更新次要版本号。
每当进行向后兼容的 bug 修复或其他不影响代码工作方式的更改时，都应递增修订号。 例如，假设你重构了 Bicep 代码以更好地使用变量和表达式。 如果重构根本没有改变 Bicep 代码的行为，则更新修订号。
管道还可以自动设置修订号。 管道的生成号可用作修订号。 此约定有助于确保版本号始终是唯一的，即使不更新版本号的其他组件。
例如，假设你使用的是以前发布的 Bicep 模块，其版本号为 2.0.496。 你发现新版本模块的版本号为 2.1.502。 唯一的明显更改是次要版本号，这表明你在使用新版本时不应期望发生中断性变更。
注意
语义化版本控制是一种形式化的版本控制结构，类似于多部分版本控制。 语义版本控制包括版本号中的其他组件，以及关于何时设置或重置每个组件的严格规则。 我们在摘要中提供了指向语义化版本控制详细信息的链接。
你的团队需要决定如何为版本控制定义中断性变更。 例如，假设你构建了一个部署存储帐户的 Bicep 模块。 现在，你正在更新 Bicep 文件，以便在存储帐户上启用专用终结点。 同时将专用 DNS 区域添加到 Bicep 文件。
在此示例中，你或许能够在不影响 Bicep 文件的参数或输出的情况下进行更改。 这样，任何部署该文件的人可能不会注意到任何不同之处。 但是，这种更改会在资源的行为方面带来显著的差异，因此你可能决定将其视为主版本更新。
还可以选择使用更简单的版本控制策略，例如仅使用管道的生成号作为版本号。 尽管这种方法更容易实现，但这意味着你无法将版本之间的差异有效地传达给使用代码的任何人。
版本和管道
以交互方式发布代码（例如使用 Azure CLI）时，你可能会考虑在发布模板规格或模块时向其分配版本号。 但在自动化部署管道中，需要更改方法来分配版本号。 管道无法自动检测中断性变更，也无法在应递增主版本号或次要版本号时向你提供建议。 在发布模板规格或模块之前，请仔细考虑版本控制。
一种方法是使用 Bicep 代码存储一个元数据文件，如下图所示：
每当更新 Bicep 代码时，就会更新相应元数据文件中的版本信息。 确保正确识别中断性变更和非中断性变更，以便正确递增版本号。
提示
如果团队使用拉取请求评审 Bicep 代码，请让审阅者验证代码的任何更改是否需要更改主版本号或次要版本号。
你将在下一个练习中了解如何使用元数据文件。
需要多少管道？
构建模板规格和模块的集合很常见。 通常，将这些代码保存在同一 Git 存储库中是有意义的。
通过在 Azure Pipelines 中使用路径筛选器，可以为存储库中的每个模块或模板规格创建单独的管道。 这种方法有助于避免每次更改一个文件时都在存储库中发布每个 Bicep 文件的新版本。 可以使用管道模板在一个集中文件中定义管道的步骤，从而使每个模块和模板规格的管道保持轻量级。
例如，假设你有一个类似于前面所示的文件结构。 可以配置三个单独的管道，每个 Bicep 文件一个。 选择每个选项卡以查看相应的管道定义及其路径筛选器：
trigger:
batch: true
branches:
include:
- main
paths:
include:
- 'module-1/**'
stages:
- template: pipeline-templates/publish-module.yml
parameters:
path: 'module-1/main.bicep'
假设仅更改 module-2/main.bicep 文件。 只有模块 2 的管道运行。 但是，如果在同一个提交中更改多个文件，则会触发每个相关的管道。
注意
为每个可重用的 Bicep 文件创建管道的方法既简单又灵活。 但是，如果有大量 Bicep 文件，或者不想为每个模块和模板规格维护单独的管道，则可能会变得麻烦。
还可以在管道中编写脚本，以查找已更改的代码并仅发布这些文件。 这是一种更复杂的方法，不在此 Microsoft Learn 模块所涉及的范围内。
可重用 Bicep 代码的环境
使用 Bicep 部署到 Azure 时，通常会使用多个环境来帮助你在代码发布到生产环境之前对其进行验证和测试。 在以前的 Microsoft Learn 训练模块中，你了解了如何通过部署管道处理多个环境。
某些组织将相同的原则应用于 Bicep 模块和模板规格。 例如，你可能首先将新版本的模块发布到非生产注册表，以便每个模块的用户都可以试用新版本。 然后，在他们注销更改后，可以将模块发布到组织的生产注册表。
与常规部署一样，可以使用作业和管道模板来定义环境中的部署顺序。 在此 Microsoft Learn 模块中，我们将发布到单个环境以保持管道的简单性。
使用注册表中的模块或使用模板规格作为 Bicep 模块时，可以使用别名。 无需在每次定义模块时都指定注册表名称或模板规格的位置，而是使用其别名。
通过使用别名，可以轻松跨多个环境执行部署过程。 例如，定义模块时，可以使用别名而不是注册表名称。 然后，可以设计部署管道以配置要映射到的别名：
- 开发模块注册表（部署到沙盒环境时）。
- 生产注册表（部署到其他环境时）。
注意
别名在发布时并不适用。 别名仅适用于在 Bicep 文件中使用模板规格或模块的情况。