Gru*_*eck 7 language-agnostic versioning
我目前正致力于自动化/改进包装我店铺整个产品的发布流程.目前该产品是以下组合:
所有或大多数都包含其中的各种版本信息,用于不同的目的.发布打包过程的一部分涉及进行大量查找,grep'ing和sed'ing(在脚本中)以更新信息.这种包装产品的胶水似乎是以有机的,及时的方式拼凑在一起,维护起来非常糟糕.例如,一些Java方法在发布时创建Date对象,其参数由文本替换更新,无需编译器验证... just,urgh.
我试图避免给出使用的实际软件的例子(即CVS,SVN,蚂蚁等)因为我想避免"使用xyz的功能来做到这一点"并且更多地关注一般实践.我想责怪这个问题的劣质设计,但如果我不得不重新开始,仍然使用不同的技术,我不确定如何最好地处理这个问题,除了制定惯例.
我的问题是,是否有关于跨不同技术,文件类型,平台和版本控制系统维护和更新版本信息的最佳实践或提示和技巧？
事实上，要完成 Craig Angus 的回答，这里的经验法则应该是不要在正常的交付文件中包含任何元信息，而是将这些元数据（版本号、发布日期等）报告到一个特殊文件中——包含在发布中——。
当您在从开发到认证再到预生产的整个过程中使用一种 VCS（版本控制系统）工具时，这会很有帮助。
这意味着每当您加载工作区（无论是用于开发、测试还是准备发布到生产环境）时，版本控制工具都会为您提供所有详细信息。
当您准备交付（一组打包文件）时，您应该向 VCS 工具询问您想要保留的每个元信息，并将它们写入一个特殊文件中，该文件本身包含在上述文件集中。
该交付应打包在外部目录中（在任何工作区之外）并且：
如果是非官方版本，则复制到共享目录（或 Maven 存储库）（但只是快速打包，以帮助隔壁等待您交付的团队）。这样，您每天可以投递 10 或 20 份，这并不重要：它们很容易被丢弃。
导入到 VCS 中以作为正式交付，并且为了轻松部署，因为您所需要做的就是向版本控制工具询问正确交付的正确版本，然后就可以开始部署它。
注意：我刚刚描述了主要用于许多相互依赖的项目的发布管理流程。对于一个小型的单个项目，您可以跳过 VCS 工具中的导入并将交付内容存储在其他地方。