这个想法是, *** 作人员只需通过执行以下方式检查初始项目:
svn co https://my-server/vs/my-project/Tags/1.0.0
之后,这些人可以在该本地SVN工作区中更改相应文件以进行配置设置.
如果有新的软件版本可用,我们只需在(自述文件旁边)分发其新版本号,例如版本1.0.1.要更新生产机器, *** 作团队只需通过执行以下命令切换到相应的工作区:
svn switch https://my-server/vs/my-project/Tags/1.0.1
(当然,在执行更新之前,必须停止运行服务器,并且在更新之后必须完成一些迁移,等等).我想指出,没有必要交付和提取TAR球,并且先前的配置设置保持不变或将与新配置线合并(好吧,这可能导致必须解决的冲突).
有没有(进一步)缺点/陷阱?您是否有更好的方法使用SVN运送软件?
提前致谢!
解决方法 这种方法的一个缺点是,您可能还没有遇到这种方法,当您将应用程序扩展到多个服务器时,这种方法对于 *** 作来说将是繁琐的.如果您突然需要4个前端服务器和2个数据库服务器,您的Ops团队将必须ssh到所有四台计算机,配置它们,然后配置数据库计算机.如果这是您在不久的将来会关注的事情,我会考虑使用像Capistrano这样的东西,它允许您一次在多台机器上部署和配置应用程序.
即使在一台服务器上为您的应用程序采用CAPIstrano的优势在于您可以从subversion获取,配置应用程序,并在一个脚本中设置数据库.
总结以上是内存溢出为你收集整理的ruby-on-rails – 如何通过SVN提供软件丢弃?全部内容,希望文章能够帮你解决ruby-on-rails – 如何通过SVN提供软件丢弃?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)