值得指出的是我们的服务器系统和应用程序的一般架构.每次开发新功能时,我们都会使用我们的应用程序(始终是我们控制的服务器)将此更新推送到所有站点.使用我们系统的每个站点实际上对95％的代码库使用完全相同的文件.我们在每个站点中有几个文件夹,其中包含定制到该站点的文件–css文件/图像等.除此之外,每个站点之间的差异由每个站点数据库中的各种配置设置定义.
这将进入实际部署本身.当我们准备推出某种更新时,我们在测试站点所在的服务器上运行命令.这将执行复制命令(cp -fru / testsite / / othersite /)并通过每个vhost强制根据修改日期更新文件.我们托管的每个附加服务器都有一个vhost,我们将生产代码库与同步,然后我们在该服务器上的所有站点上重复复制过程.在此过程中,我们移出了我们不想被覆盖的文件,在复制完成后将它们移回.我们的rollout脚本执行许多其他功能,例如应用sql命令来更改每个数据库,添加字段/新表等.
我们越来越担心我们的过程不够稳定,不容错,也是一种蛮力方法.我们也意识到我们没有充分利用颠覆,因为我们有一个位置,即在我们不使用分支或标签时,处理新功能会阻止我们推出重要的错误修复.我们在服务器上进行了如此多的文件复制似乎也是错误的.我们也无法轻松地对刚刚推出的内容进行回滚.我们在每次推出之前都会执行差异,因此我们可以获得将要更改的文件列表,以便我们知道之后已经更改的内容,但回滚过程仍然存在问题.就数据库而言,我已开始将dbdeploy视为一种潜在的解决方案.我们真正想要的是关于如何改进文件管理和部署的一般指导.理想情况下,我们希望文件管理与我们的存储库更紧密地链接,因此rollout / rollback将更多地连接到svn.比如使用export命令确保站点文件与repo文件相同.如果解决方案可能也会停止我们服务器周围的文件复制,那也不错.
忽略我们当前的方法,听听其他人如何处理同样的问题真的很好.
总结一下……
>制作文件的最佳方式是什么
跨多个服务器保持同步
与svn？
>我们应该如何防止文件
复制？符号链接/东西
其他？
>我们应该如何构建我们的回购
我们可以开发新功能并修复旧功能
那些？
>我们应该如何触发
首次展示/回滚？
提前致谢
编辑：
最近我读了很多关于使用Phing和Capistrano来完成这些任务的好东西.任何人都可以提供更多关于它们的信息以及它们对于这种任务有多好吗？
现在,当您收到错误报告时,您将此修复程序提交给分支并将其移植到主干.当您对修复的错误数量感到满意时,您可以标记和部署维护版本.
重要的是,您的实时代码库的分支(或者能够通过了解实时修订创建一个分支)与开发分支分开,这样您就可以将修复程序部署到实时代码而无需部署新功能或未经测试的代码.
我建议使用您的发行版的本机打包系统来部署新代码.如果你有一个包含所有代码库的软件包,你知道你的所有代码都是在一种原子操作中部署的,你可以一目了然地查看安装的版本,可以使用软件包校验和来验证你的代码库.回滚只是安装以前安装的软件包版本的一种情况.
我可以看到实现这一点的唯一障碍是,您似乎拥有在单个服务器上运行的不同客户的代码库的多个副本.我会尝试安排您的代码,以便所有客户都使用相同的文件并且不使用副本.我不知道这对你有多容易,但减少你必须处理的副本数量将大大减轻你的头痛.
我假设你提到LAMP时,你正在使用PHP或其他脚本语言,这不需要编译过程.这意味着你可能错过了一个名为持续集成的精彩过程.这基本上意味着你的代码不断被测试,以确保它仍处于可释放的状态.每次有人检查新代码时,进程都会接受并运行构建和测试过程.使用编译语言,您通常会使用它来确保代码仍然编译.你应该利用每种语言运行单元测试(你的代码是可测试的单元不是吗？)和集成测试.对于网站来说,测试集成测试的一个好工具是Selenium.在我们的Java构建中,我们还测量代码覆盖率和代码度量,以了解我们如何随着时间推移而进展.我们为Java找到的最好的CI服务器是Hudson,但像buildbot这样的东西可能更适合其他语言.您可以使用CI服务器构建包.
