Roe*_*and 5 svn version-control workflow
我和我的兄弟和朋友一起经营一家小型网络开发公司.经过广泛的研究后,我决定使用subversion进行版本控制.
以下是我目前计划运行典型开发的方法.请记住,我们每个人都在一个单独的位置.
我用springloops(springloops.com)subversion托管设置了一个帐户.每次我处理一个新项目时,我都会为它创建一个存储库.所以我要说在这种情况下我正在使用site1.我想在互联网上有3个版本的网站:
每个Web开发机器(在每个位置)都将拥有运行虚拟主机的xamp的本地副本,以允许处理多个网站.本地副本的根目录设置为与subversion存储库的本地副本相同.这是设置所以我们可以进行小调整并立即预览它们.完成某些工作后,将对该站点的存储库进行提交.我将自动推送开发站点(它是springloops中的一个选项).然后,每当我准备好推送到客户端站点时,我都会这样做.最后阶段将是推送到现场.
现在,我对这些工作流程有一些顾虑:
我目前正在使用codeigniter,在配置文件中我通常设置网站的根目录.防爆. http://www.site1.com.因此,看起来每次我发布到其中一个互联网服务器,我将不得不修改配置文件?有没有办法让它为每个服务器设置某些文件?因此,当我点击发布到客户端预览时,它只会上传客户端预览服务器的配置文件.
我不希望实时站点,客户端预览站点和开发站点出于各种原因共享同一个mysql服务器.那么这又是否意味着我每次推送到不同的站点时都必须调整数据库服务器信息?
这个工作流程有意义吗?如果您有任何建议,请告诉我.我计划将此作为我未来几年使用的工作流程.我只需要建立一个允许未来扩展的系统!
1)研究持续集成的概念。(有十几个免费的小型项目 CI 服务器,例如 TeamCity)
2) 1. 准备能够针对您的三个环境中的任何一个的部署过程
3) 考虑始终检查部署站点上的用户是否可以访问 .svn 文件,因为它确实不安全
另请阅读有关在 SVN 中使用标签/分支的内容
接下来,我建议以下工作流程
第一种情况(简单)每个人都进行结帐并在本地副本上工作。提交(经过充分测试)一定量的新功能后,您将触发(可能自动)构建预览预览经过全面测试后,您将触发构建生产
第二种情况(更好)每个人都会在每次大量的更改上创建一个分支,并且可以自由地将任何内容提交到自己的分支。拥有分支稳定分支后,您将其合并到主干,这将触发测试机检出并构建您命名的预览并标记标签全面测试的预览将转到发布分支
拥有这么多分支的目的是能够同时存储个人更改历史记录和稳定版本。