我们如何跟踪每种环境中的代码版本？

我的团队目前使用相当简单的分支/部署过程，如下所示：

                ┌────────┐ ┌────┐ ┌──────┐
 Environments:  │  DEV   │ │ QA │ │ PROD │
                └────────┘ └────┘ └──────┘

                     ▲       ▲       ▲
                     │       │       │

                ┌────────┐ ┌────┐ ┌──────┐
 Builds:        │  DEV   │ │ QA │ │ PROD │
                └────────┘ └────┘ └──────┘

                     ▲       ▲       ▲
                     │       │       │

                ┌────────┐ ┌────┐ ┌──────┐
 Branches:      │ master │ │ qa │ │ prod │
                └────────┘ └────┘ └──────┘

每个环境都有其自己的分支（我们使用git）和使用该分支的自己的构建。当我们想要从一个环境升级到另一个环境（例如，从DEV升级到QA）时，我们将master分支合并qa并启动新的QA构建（然后将其自动部署到QA环境）。

我们正在考虑采用一种新的流程，该流程将取消拥有专门的分支机构并针对每个环境进行构建的流程。相反，单个发行版本将创建一个“部署包”，然后可以将其部署到任何环境中。我们正在想象一个典型的工作流程如下所示：

                ┌────────┐     ┌────┐     ┌──────┐
 Environments:  │  DEV   │ ──► │ QA │ ──► │ PROD │
                └────────┘     └────┘     └──────┘

                      ▲ 
                       \ 

                        ┌───────────────┐
 Builds:                │ release build │
                        └───────────────┘

                                ▲
                                │

                ┌────────┐ ┌─────────┐
 Branches:      │ master │ │ release │
                └────────┘ └─────────┘

从一种环境升级到另一种环境将不再由源代码控制处理；相反，我们只是采用已经构建的二进制文件（“部署程序包”），然后将其放到新环境中。

这个新系统将使我们能够将任何构建部署到任何环境，这具有多个优势。例如，在DEV和QA中测试PROD错误修复很简单。我们当前的系统无法提供一种不回滚分支的简便方法，这显然是我们希望避免的。

这个新系统的最大缺点是我们不再拥有一种自动的方式来跟踪哪种环境中的代码。如果需要在PROD中进行修复，则不再需要与当前生产代码库同步的专用分支。质量检查也是如此-如果我们希望快速更改质量检查而又不从中拖延正在进行的工作master，我们将不再有一个分支来反映质量检查环境的当前状态。

我们如何跟踪每种环境中的代码？

我们正在考虑的一些选择：

• 利用git标签来跟踪哪个环境中的提交
• 将构建使用的git commit嵌入到每个部署包中

Git标签是您真正想要用来指定发行版的标签。原因是它们对您具有意义，可用于快速识别状态已部署的代码与构建服务器可能具有的任何信息（例如构建号）之间的联系。

虽然这是您要寻找的答案，但只能解决一半的问题。另一个是“嘿，这是.[wje]ar服务器上的部署，它来自什么版本？” 我们知道您将永远不会在dev和qa或prod上部署不同版本的应用程序。对？

该部分问题的解决方案是让构建服务器将信息放入清单中。来自我面前的一个Maven和svn示例：

<manifestEntries>
    <Specification-Title>${project.name}</Specification-Title>
    <Specification-Version>${project.version}</Specification-Version>
    <Build-Number>${build.number}</Build-Number>
    <Build-Id>${build.id}</Build-Id>
    <Svn-Revison>${svn.revision}</Svn-Revison>
</manifestEntries>

那就是在maven-war-plugin档案配置中。但是您也可以在其他插件中找到它。然后在哈德森，Maven构建调用的一部分是：

-Dbuild.number=${BUILD_NUMBER}
-Dsvn.revision=${SVN_REVISION}
-Dbuild.id=${BUILD_ID}

设置那些定义，然后行家接手。然后，只需查看已部署在服务器上的MANIFEST.MF文件即可查看其版本。

有一个git插件，提供了一组相似的环境变量，包括：

• GIT_COMMIT -当前的SHA
• GIT_BRANCH -远程存储库的名称（默认为原始名称），后跟当前使用的分支名称，例如“ origin / master”或“ origin / foo”

结合这两种做法，您可以轻松识别构建（因为构建编号是向前的，并且与sha校验和不同，因此具有含义）以及构建所基于的特定git commit。

完全不同的方法是放弃versions完全的想法。您只有“一个版本”，它具有不同的可配置行为。唯一的区别是，您具有通用的代码库-即使在生产环境中，您也将部署进行中的工作：但未激活。

区别仅归结为产品中启用的不同功能集。

停用 /激活是通过功能切换完成的。

好处：简化了整个发行过程：您始终在交付软件的集成版本。中的每个功能始终可用master。不需要其他分支。

合并要素不会带来痛苦，因为：没有分支，无需合并。不会混淆哪个特征在哪个分支上，并且可能依赖于其他分支的特征或与之冲突。每个部分都可以随意激活。甚至不再需要回滚：只需按一下开关即可。

我不知道这是否适用于您的代码库：代码质量和开发人员纪律方面的前提条件非常高-在功能成为核心功能之后，您必须处理“清理”，并且必须管理大量切换防止更大的混乱。

也许对您有用。

我们使用maven将版本放入清单文件中。然后，如果应用程序是Web应用程序，则让该应用程序显示版本，或者具有Web服务的/ version端点。