java - 当特定类成员在发布版本之间更改值时破坏 Maven 构建的良好实践

Question

在定期发布新版本的正在进行的 Java 语言 Maven 多模块项目中，源代码中的一些常量值需要随着时间的推移保持不变，即使在后续的新版本中也是如此。这些常量的模式如下:

public static final String GREMLIN_VITALITY_EXCITED_DB_FIELD_KEY = "excited";

如果开发人员发现一个已经在代码中交付到生产环境的值，并更改了该值，并且该更改使其成为 future 交付的可交付成果，则随后的版本将携带更改后的值并造成严重破坏，可能会导致数据丢失和困惑顾客。我力求使这些常量不易被开发人员更改，即使是通过较新的版本也是如此。

你可能会问为什么？我当前正在研究的一个特定领域是确保数据库升级系统中特定数据库模式版本的值正确，该系统按版本步骤执行累积升级，其中依赖于特定常量且不得更改。类似地，另一个区域是 REST API 中传递的某些值。

我正在寻找一种有效的技术解决方案，最好是一个非常简单的解决方案，它有助于系统地消除更改一组 Java 语言常量值的能力，或者至少自动检测禁止更改的能力(如上所述) )，并且最好是在 Maven 构建期间，以便所有开发人员停止生产线，直到得到纠正。

当然，有代码审查可以帮助筛选此类违规行为，尽管是由容易犯错的人执行的。到目前为止，我们每个人都只信任自己和彼此；自动化的预防系统(或者，我们将勉强接受单纯的检测)将满足我们风险承受能力中剩余的、 Unresolved 部分。

到目前为止我们考虑过的事情:

• 尝试语言结构以防止发生变化。没发现有这样的事。相当快。因为源代码可以更改、提交并合并到发布分支中。
• 手动整理编译的类文件。棘手意味着操作“失误”的倾向没有被系统性地消除。
• 将具有永久不变的 Java 语言“常量”的类隔离到单独的 Maven 模块中。管理过程更加经过深思熟虑，包括文件编辑和更新依赖模块中的 Maven 依赖项 GAV，但机器仍然无法为我们检测值更改，并且仍然容易出现人为错误。
• 确定解决此问题的 Maven 机制。也许有一个注释，我们可以将其应用于适当的常量，并在与 MVN 存储库中找到的先前版本比较失败时中断构建？唉，我们的 Google-fu 似乎还不够。
• 使用 Clirr 来识别 Not Acceptable 更改并中断构建。但是，Clirr 似乎只检测接口(interface)定义(“公共(public) API”)的更改。
• 如果构建系统中检测更改的相关部分本身发生更改，则会发出不同且适当的警告信号。因此，这种情况我们并不担心。

Answer 1

这就是单元测试的用途。 Maven 将在构建之前测试代码。

或者，您可以使用 .properties 文件，并将所有常量值放在那里。因此，部署后您只需确保一个属性文件是正确的即可。