工件的版本控制 - CI/CD答案

【问题标题】：Versioning of artifacts - CI/CD工件的版本控制 - CI/CD
【发布时间】：2019-08-15 11:24:27
【问题描述】：

java 代码的构建过程当前正在生成名称没有版本号的工件。

例如：serial-framework-SNAPSHOT.jar

我们目前处于 CI/CD 管道的构建阶段

所有通过 maven build 生成的工件都没有后端服务的版本号，处于 CI/CD 管道的构建阶段

构建特定 jar 所需的相关工件仅存储在 JFrog 工件中

1) 它是否需要对 CI/CD 管道的 Build/QA/prod 阶段的工件进行版本控制？

2) 是否需要将每个工件都存储在 JFrog 工件中？因为只有在 maven 构建期间 pom.xml 需要的依赖工件存储在 JFrog 中

【问题讨论】：

【解决方案1】：

snukone 在第一个答案中很好地解释了版本控制。注意以下几点可能对版本控制有帮助

对于开发，请始终遵循“versionNumber-SNAPSHOT”（大写字母）的版本例如：- 1.0 -SNAPSHOT

2) 对于 test/prod 分支，版本号为“versionNumber-RELEASE” 例如：- 1.0 – 发布

a) 快照是可变的，因此它们用于开发目的。

b) 发布是不可变的。一旦提交，我们就无法覆盖神器。所以发布用于更高的环境。

c) 快照捕获正在进行的工作并在开发过程中使用。快照工件具有版本号（例如“1.3.0”或“1.3”）和时间戳。例如，commons-lang 1.3.0 的快照工件可能具有名称 commons-lang-1.3.0-20090314.182342-1.jar

因此，在您的情况下，如果您使用“serial-framework-SNAPSHOT”，它将在您的工件中存储为“serial-framework-version-timestamp.jar”。

同样，如果您使用“serial-framework-RELEASE”，它将在您的工件中存储为“serial-framework-version.jar”。

【讨论】：

【解决方案2】：

版本控制如何帮助：

版本控制有助于您恢复旧版本的应用程序（由于错误会严重降低生产中的性能）
如果您在 api 或 ui 级别运行集成测试，您可以指定哪些版本适合在一起（即通过合同测试：https://github.com/pact-foundation/pact_broker）
默认清理过程可帮助您防止您的工件使用大量存储空间

是否存储每个工件？

我的个人经验：只需存储依赖于其他工件的工件。以 Libs 为例。如果您正在使用 Docker 容器，您应该考虑对每次构建时生成的 Docker 映像进行版本控制。

【讨论】：

是否，dev 管道工件版本应该不同于 QA 管道生成工件版本与 prod 管道工件版本不同？如果是，为什么？
您在三个不同的管道中生成三个不同的工件，我说得对吗？三种神器有什么区别？例如，如果开发管道生成 Web 应用程序 WAR 和 qa 管道测试结果，您可以使用 maven 分类器来区分两者。
开发管道生成一个具有单元+集成测试结果的 WAR。 QA 管道仅在发布日期即将到来时才考虑。在变化方面没有太大的不同。大多数集成测试应该在开发管道中完成
是否可以在 qa 和 prod 管道中使用在开发管道中生成的相同工件？因此，您正在节省资源。我们有一个 ci 和一个输送管道。在 CI 中构建和测试应用程序。在交付管道中，我们只检查工件的某些规则是否为真，并将它们部署在 prod 中。如果您使用的是 maven 发布插件，您可以通过 Parameter 控制发布的创建，或者使用一个用于快照和一个用于发布。