您将推荐或使用什么工具和过程来帮助简化以下场景：(我知道这是一个漫长的过程,但是可以提供任何帮助)
我在一个团队中工作,该团队拥有我们在公司开发的电子商务应用程序.它是我们已经开发了大约3年的合理标准的LAMP应用程序.我们在测试域上开发应用程序,在这里我们添加了新功能并修复了错误等.我们的错误跟踪和功能开发都在托管的Subversion解决方案(unfuddle.com)中进行管理.当报告了错误时,我们在测试域上进行了这些修复,然后在满意的情况下将更改提交到svn.我们遵循相同的步骤,但增加了新功能.
值得指出的是我们整个服务器上系统和应用程序的一般体系结构.每次开发新功能时,我们都会使用我们的应用程序(始终由我们控制的服务器)将此更新发布到所有站点.使用我们系统的每个站点在95％的代码库中基本上使用完全相同的文件.每个站点中都有几个文件夹,其中包含该站点定制的文件-css文件/图像等.除此以外,每个站点之间的差异是由每个站点数据库中的各种配置设置定义的.
这涉及到实际的部署本身.当我们准备推出某种更新时,我们会在测试站点所在的服务器上运行命令.这将执行复制命令(cp -fru / testsite / / othersite /),并通过每个vhost强制根据修改的日期更新文件.我们托管的每个其他服务器都有一个虚拟主机,我们将生产代码库同步到该虚拟主机,然后在该服务器上的所有站点上重复复制过程.在此过程中,我们将不想覆盖的文件移出,在复制完成后将它们移回.我们的发布脚本执行许多其他功能,例如应用sql命令更改每个数据库,添加字段/新表等.
我们越来越担心我们的过程不够稳定,不能容错并且还有些蛮力.我们也意识到我们没有充分利用Subversion,因为我们有一种立场,即使用新功能会阻止我们推出重要的错误修复程序,因为我们没有使用分支或标签.我们在服务器之间进行了如此多的文件复制,这似乎也是错误的.我们也无法轻松地对刚刚推出的内容进行回滚.我们确实在每次推出之前都执行了diff操作,因此我们可以获得将要更改的文件的列表,因此我们知道之后进行了哪些更改,但是回滚过程仍然存在问题.在数据库方面,我已经开始研究dbdeploy作为潜在的解决方案.不过,我们真正想要的是有关如何改善文件管理和部署的一些常规指导.理想情况下,我们希望文件管理更紧密地链接到我们的存储库,以便将首次推出/回滚与svn连接起来.类似于使用export命令来确保站点文件与回购文件相同.但是,如果该解决方案也可以停止我们服务器周围的文件复制,那也将很好.
总结一下…
我们应该如何构造我们的仓库,以便我们可以开发新功能并修复旧功能？
我们应该如何触发部署/回滚？
提前致谢.
解决方法:
为了回滚和测试新功能,分支和标签的标准Subversion概念应该足够了：
>始终在推出之前创建标签,然后推出该标签.然后,回滚将意味着返回到先前的标签.
>在分支机构中开发新功能,并在完成后合并到主干中；或者,在中继中开发新功能,并拥有一个仅接收错误修复的维护分支.
>将每个站点的文件保存在Subversion的单独目录中,并在每个站点上使用配置文件或符号链接,以使站点引用其特定文件.
为了减少文件重复,我建议使用NFS(尤其是当所有站点都是同一主机上的虚拟机时-使主机成为NFS服务器,使站点成为NFS客户端；或者使专用VM成为NFS服务器).要部署更新,请仅在NFS服务器上安装新文件；否则,请执行以下步骤.客户将自动获取更改.
如果您需要多步骤更新(例如,首先更新每个客户端中的数据库,然后更新代码),则仍应使用NFS,但要在其上添加符号链接.将新代码检出到NFS服务器上的单独目录中,然后转到所有VM,更新数据库,然后更改VM中的符号链接以指向新代码.完成后,删除NFS服务器上的旧代码.
原文地址：https://codeday.me/bug/20191107/2002661.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
