持续交付 的基本原则之一是 B uild B inaries Only Once ，简称 BBOO。这意味着二进制工件应该构建一次，而且只能构建一次。然后应将这些工件存储在存储库管理器中，例如 Nexus Repository 。随后的部署、测试和发布周期永远不应尝试再次构建此二进制文件，而是重用此二进制文件。这可确保完全相同的二进制文件经过所有不同的测试周期并交付给客户。
在每个测试阶段使用工作区的特定标记多次重建二进制文件，并认为它们是相同的。但那还是不一样！结果可能是一样的，但这是偶然的。由于不同的环境配置，它很可能不一样。例如，开发团队可能在他们的机器上使用 JDK 8，而测试/暂存可能使用 JDK 7。导致二进制工件不同的原因有很多。因此，只构建一次二进制文件，将它们存储在存储库中，并让它们经历不同的测试、暂存和生产周期是非常重要的。这提高了交付给客户的总体信心水平。
此图像显示二进制文件如何在构建阶段构建一次并存储在 Nexus 存储库中。此后，部署、测试和发布阶段仅从 Nexus 读取二进制文件。
开发、测试和登台环境不同的事实是一个不同的问题。我们将在随后的博客中处理这个问题。
您如何设置一次构建二进制文件？
现在，让我们看看设置：
- 一次构建 Java EE 7 应用程序 WAR 文件
-
存储在 Nexus 存储库或
.m2本地存储库中 - 相同的二进制文件用于冒烟测试
- 相同的二进制文件用于运行完整的测试套件
我们案例中的冒烟测试将只是一个测试，而完整套件有四个测试。希望这不是您在测试数量方面的典型设置，但至少您可以了解如何设置所有内容。
也只有两个阶段的测试，冒烟和完整，但这个概念可以很容易地扩展到添加其他阶段。随后的博客将展示一个完整的部署管道。
让我们开始吧！
- 从 github.com/javaee-samples/javaee7-simple-sample 查看一个简单的 Java EE 7 示例应用程序。这是一个典型的 Java EE 应用程序，具有 REST 端点、CDI bean、JPA 实体。
-
设置
本地 Nexus 存储库
并将应用程序的快照部署到它：
mvn deploy
默认情况下，Nexus 存储库配置在localhost:8081/nexus上。如果您使用不同的组合，请记下主机/端口。还要记下部署到 Nexus 的确切版本号。默认情况下，它将是1.0-SNAPSHOT。您还可以将 RELEASE 部署到此 Nexus 存储库，如下所示：
记下您部署的是 SNAPSHOT 还是 RELEASE。在任何一种情况下，您还可以指定mvn deploy-P releaseMaven 配置文件和源代码，并且 javadocs 将与部署一起附加。因此，如果 RELEASE 部署为：
然后还附上源代码和 javadoc。mvn deploy -
从
github.com/javaee-samples/javaee7-simple-sample-test
查看测试工作区。在此项目中进行以下更改：
-
更改
nexus-repo属性以匹配 Nexus 存储库的主机/端口。如果您使用 Nexus 的默认安装并部署了一个 RELEASE，则无需更改任何内容。默认情况下，Nexus 有一个用于 SNAPSHOT 的存储库和另一个用于 RELEASE 的存储库。工作区配置为使用 RELEASE 存储库。如果您部署了快照，则需要将nexus-repo中的“releases”更改为“snapshots”以指向适当的存储库。 -
更改
javaee7-sample-app-version属性以匹配部署到 Nexus 的应用程序的版本。
-
更改
-
启动 WildFly 并运行冒烟测试：
这将运行所有以“SmokeTest”结尾的文件。 ShrinkWrap 和 Arquillian 执行从 Nexus 解析 WAR 文件并使用它运行测试的繁重工作：mvn deploy
运行冒烟测试会将结果显示为：mvn deploymvn deploy -
运行完整的测试：
这将运行您的测试套件中包含的所有文件，并将结果显示为：mvn deploy
在这两种情况下，冒烟测试和完整测试都使用部署到 Nexus 的二进制文件。mvn deploy
