Question

我们正在开发由许多独立服务组成的应用程序。它比单一的单片应用程序有优势，但在我们发布时却没有。

我们每周发布一次。每个服务/组件位于单独的git存储库中。 '发布' - 是我们投入的一些功能。通常只应更新几个组件。我们使用saltstack管理服务器。要使用git.latest状态来发布salt脚本更新组件的版本。问题是指定正确的版本。

这是我想要自动化的手动工作。要更新版本，我必须手动检查每个组件的存储库，根据symantec版本规则将开发分支合并为master和tag。然后我在salt脚本中编写新版本。我们有超过10个组件，因此这是一个相当无聊且容易出错的过程。

可能我们做错了，我很乐意听到有关如何做得更好的建议，谢谢。

Answer 1

首先，我建议遵循组件发布标记的约定。在最简单的情况下，这将是每个存储库中最新鲜的git标记。

然后，您可以创建一个映射脚本（例如，它称为map_versions），枚举所有存储库的发布（最新）git标记，并将该映射存储在某个地方，以便SaltStack将其接收到 - 用作revision州的git.latest - 。

相同的映射脚本也可用于准备部署的所有组件的develop or master分支， - 所有revision值都将切换为develop或{{1 }}

因此，您的工作流程将是：

master

之后，生产中所有已发布的组件都会被标记。

您还可以使用自动git-tagging脚本为所有可部署组件节省一些时间。该脚本将检查自上一个标记以来// In the dev environment: $ map_versions develop $ salt * state.highstate // Do the development, until all the stable features // are merged back into master. Then, in production: $ map_versions master $ salt * state.highstate // Make sure everything works fine; then, manually tag // the new release versions for all the repos. $ map_versions tags $ salt * state.highstate中是否有任何更改，如果有，则会在repo上粘贴新的git标记;比如今天的master。然后，这些标签将由YYYY-MM-DD提取。

Answer 2

您可以在单独的git repo中为要包含在发行版中的每个组件（以及可能需要的其他元数据信息）保留显式版本映射，这将成为您的主 SCM控制旋钮。这提供了几个优点：

不将脚本/代码与元数据信息混合（容易出错）
您可以编写脚本代码，只需处理来自此主git仓库的版本控制信息，无需为每个版本更改脚本
您只需跟踪/标记主git仓库，因为它包含有关发布所需的所有其他组件的所有元数据信息 - 更少SCM流失
您可以通过这个小型回购快速访问所有组件的相关元数据信息，无需拉动整个组件（除非您还需要专门访问其内容）
你可以防止污染组件＆＃39; SCM记录您的特定发布信息（如果这些组件与其他完全不相关或第三方产品共享，尤其重要，这些产品对您的特定发布周期不太关心）。

这并不能消除您必须执行的发布步骤，它只是添加了一些订单，可以帮助实现自动化。

Answer 3

我认为您正在寻找的工具是一个git hook。

我个人可能会在您的存储库中设置一个服务器端post-receive hook [0]，它接受语义标记并自动更新支柱数据中的软件版本，或创建一个Salt事件触发使用提供的数据进行更新或部署。

还有外部支柱数据源[1]的选项，它可以自动获取最新的标签或在git的主分支上提交。

在任何一种情况下，我都会保持git合并并标记手动步骤。

[0] http://www.git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

[1] http://docs.saltstack.com/en/latest/topics/development/external_pillars.html

Answer 4

在开发和管理由微服务构建的平台发布一年多之后，我想到了可以自动化的可重复过程。更多内容如下。

让我们将发布过程分为 3个阶段：

了解发布时应该发布的内容
准备变更
在狂野中推他们

我们正在使用Git和A successful Git branching model，这是相当可疑的，我更喜欢FeatureBranch工作流程，但这是一个不同的故事。

第一阶段：了解应该发生什么

在我们的问题跟踪工具中，应该出现的故事标记为“准备合并”（我们使用jira.com但无所谓）。我抓住故事列表，运行看起来像mia review --cards=MIA-1022 MIA-988 MIA-1097 MIA-688的简单脚本。输出是受这些故事影响的服务列表，因此您无需手动查看每个故事以查看受影响的服务，示例输出如下所示：

[+] [2/16] user-service: MIA-1198, MIA-2023
[+] [6/16] checkout-service:  MIA-1097 MIA-688
[+] [7/16] inventory-service: MIA-1022 MIA-988, MIA-1198, MIA-2023

第二阶段：准备更改

对我来说是半手动过程，因为在某些情况下，来自 develop 分支的“进行中”故事需要被忽略而无法掌握。但在大多数情况下，我可以将 develop 直接合并到 master ，当我可以的时候，我还有另一个命令：mia merge --services=user checkout inventory。此命令将覆盖指定的服务，创建请求以将开发分支合并到主，并打印出拉取请求的链接。

第三阶段：推动野外变化

要将某些内容推送到暂存环境然后再投入生产，服务必须具有版本。根据经验，我们认为如果你做服务的semver，而且如果你只为有变化的服务做，那么很难理解“最新”。因为如果结账服务的发展速度明显高于库存服务，你最终会得到结账时的v3.3.6和库存中的v1.2.0。

所以解决这个问题：我们使用由年，月，日和rc版本组成的相同标签版本标记所有服务。示例： r2015052601 ，然后我们还有一个命令mia diff r2015052401 r2015052601，它在每个服务中搜索指定的标记，并在两个标记之间打印更改差异。我的一部分认为用相同版本标记所有服务违反了微服务架构的原则之一，但对我们来说，它现在解决了标签兼容性和理解最新问题的主要痛点，因为你可以假设最新的标签存在于任何地方，如果没有变化，然后没有变化。

由于

基于微服务的应用程序版本的自动化

4 个答案: