我希望重新组织我们发布内部软件的方式。所有代码(PHP webapps,一些Java应用程序和Perl脚本)都被检入Subversion存储库,但是没有分支或标记,所有内容都被检入trunk(每个应用程序只有1-3个devs)。在生产Linux服务器上,该软件只是直接从一个正常运行的svn副本运行(实际上大多数变化都发生在那里)。
由于我们有很多小型应用程序并且经常会对正在运行的系统进行小的更改,因此我正在寻找一种非常精简或透明的方式来进行一些发布工程并清理这种混乱。
是否有任何工具可以帮助我在异类环境(语言方面)这样做? 或者有谁知道如何以适当的方式做到这一点?
否则我会考虑编写一些发布(shell)脚本,这些脚本会自动从trunk创建subversion标签,然后检查生产服务器的相应标签。但这对我来说听起来有点黑客。
谢谢,
黑斯。
答案 0 :(得分:1)
使用标签和分支;使其成为开发周期的一部分。当您更新“stable-1.0”分支时,测试了更改并将其标记为“release-1.0.5”,您只需在服务器上执行“svn switch”到新标记。尽管经过测试,但没有工作?切换回来,弄清楚出了什么问题。
但要注意,颠覆中的分支可能是一种痛苦,至少在1.5版本之前。如果您或您的开发人员没有分支经验,那么在开始时会遇到一些麻烦和/或错误。但只要你承诺就不会丢失代码(最糟糕的是很难合并)。
您的开发人员应该学习如何使用分支;它可以用于各种目的(不仅仅是发布工程)。
不自动切换生产服务器上的代码;有人可能不小心碰到了错误的按钮。应始终谨慎地进行生产更新。添加新标签的脚本由于其简单性而不必要,但您的里程可能会有所不同。
最后一点,不要让任何人对您的生产服务器进行更改。它可能会导致冲突,而这些冲突往往需要时间来解决。更不用说,它会破坏你在不同工作站上重现某个版本的能力(这里工作得很好!为什么不在服务器上呢?嗯)。
答案 1 :(得分:1)
持续集成绝对是可行的方法 - 任何CI(即使是极简主义批处理文件)总比没有好 - 但它只会与您现有的策略一样好。由于您的文件实际上并不是“二进制”或“可分发”,因此标记版本可能只需要您标记存储库,甚至只需将Subversion版本号存储在某处。您需要的重要策略是,任何版本都可以在您需要时重建 - 因此您可以比较当前和以前的版本,或者如果出现问题则返回旧版本。不要担心在svn中创建标签的“开销” - 这非常有效。
执行subversion标记的发布脚本听起来不错。 CI实现(我建议使用CruiseControl,因为它是异构工作的理想选择,虽然异构性需要更多的配置开销)很棒,因为你可以在subversion checkin上自动启动流程,并运行自动化测试来确定它是否良好足以标记与否。
我绝对不会自动部署到发布服务器。一个'临时区'(称之为'夜间构建','beta测试',无论如何)会更好。在您决定将其推广到生产服务器之前,让您的用户远离它。并且,只要您已经获得了可以回滚到早期版本的策略,就可以减少推出错误的可能性。
自动结账到生产服务器是唯一的“hackish”部分 - 自动结账,测试,标签,beta部署足够灵活。然而,推广到生产不应该有一个简单的按钮。
答案 2 :(得分:0)
某些持续集成服务器执行此类操作,例如Hudson具有subversion集成。它可以为您标记,运行测试和部署。
答案 3 :(得分:0)