使用 Subversion 与 2-3 人一起建立完美的 Web 开发工作流程
我与我的兄弟和朋友一起经营一家小型网络开发公司。经过广泛的研究后，我决定使用 subversion 进行版本控制。
以下是我目前计划如何运行典型开发。请记住，我们 3 个人都在不同的位置。
我在 springloops (springloops.com) subversion 托管上设置了一个帐户。每次我处理一个新项目时，我都会为其创建一个存储库。假设在本例中我正在 site1 上工作。我想在互联网上拥有 3 个版本的网站：
- Web 开发 - 这是服务器 我和其他开发者发布 到。 (site1.dev.bythepixel.com)
- 客户端预览 - 这是服务器 我们每隔几天更新一次 很好的修改供客户查看。 (site1.bythepixel.com)
- 实时站点 - 我在上线时发布到的站点 (site1.com)
每个 Web 开发计算机（在每个位置）都会有一个运行虚拟主机的 xamp 本地副本允许在多个网站上工作。本地副本的根目录设置为与 Subversion 存储库的本地副本相同。这样设置是为了让我们可以进行一些小的调整并立即预览它们。完成某些工作后，就会向站点的存储库进行提交。我将自动推送开发站点（这是 springloops 中的一个选项）。然后，每当我准备好推送到客户端站点时，我就会这样做。最后阶段将是推送到现场。
现在，我对这些工作流程有一些担忧：
我当前使用的是 codeigniter，并且在配置文件中我通常设置站点的根目录。前任。 http://www.site1.com。那么，看起来每次我发布到其中一台互联网服务器时，我都必须修改配置文件？有什么方法可以为每个服务器设置某些文件吗？因此，当我点击“发布到客户端预览”时，它只会上传客户端预览服务器的配置文件。
出于各种原因，我不希望实时站点、客户端预览站点和开发站点共享同一个 mysql 服务器。那么这是否再次意味着我每次推送到不同的站点时都必须调整数据库服务器信息？
这个工作流程有意义吗？如果您有任何建议，请告诉我。我计划将其作为我未来几年使用的工作流程。我只需要建立一个允许未来扩展的系统！
I run a small web development company along side with my brother and friend. After doing extensive research I have decided on using subversion for version control.
Here is how I currently plan on running typical development. Keep in mind there are 3 of us each in a separate location.
I set up an account with springloops (springloops.com) subversion hosting. Each time I work on a new project, I create a repository for it. So lets say in this case I am working on site1. I want to have 3 versions of the site on the internet:
- Web Development - This is the server
me and the other developers publish
to. (site1.dev.bythepixel.com) - Client Preview - This is the server
that we update every few days with a
good revision for the client to see.
(site1.bythepixel.com) - Live Site - The site I publish to when going live (site1.com)
Each web development machine (at each location) will have a local copy of xamp running virtual host to allow multiple websites to be worked on. The root of the local copy is set up to be the same as the local copy of the subversion repository. This is set up so we can make small tweaks and preview them immediately. When some work has been done, a commit is made to the repository for the site. I will have the dev site automatically be pushed (its an option in springloops). Then, whenever I feel ready to push to the client site I will do so. The final stage will be to push to the live site.
Now, I have a few concerns with those work flow:
I am using codeigniter currently, and in the config file I generally set the root of the site. Ex. http://www.site1.com. So, it looks like each time I publish to one of the internet servers, I will have to modify the config file? Is there any way to make it so certain files are set for each server? So when I hit publish to client preview it just uploads the config file for the client preview server.
I don't want the live site , the client preview site and the dev site to share the same mysql server for a variety of reasons. So does this once again mean that I have to adjust the db server info each time I push to a different site?
Does this workflow make sense? If you have any suggestion please let me know. I plan for this to be the work flow I use for the next few year. I just need to put a system in place that allows for future expansion!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于分布式版本控制系统来说，有比 Subversion 更好的版本控制解决方案，我强烈建议您研究其中之一：
请参阅此处，此处和此处< /a> 对于一些不科学的讨论
，正如 vittore 所说，我认为 CI 解决方案非常有用，它可以自动将您从开发环境推送到“生产”，客户可以在成功的构建/测试中看到它循环。
There are better version control solutions for distributed version control systems than subversion, I would highly recommend looking into one of these:
see here, here and here for some unscientific discussion
also, as vittore said, I would consider a CI solution to be quite useful, that could automate your push from the dev environment over to "production" where the client could see it on a successful build/test cycle.
1）研究持续集成的概念。 （有十几个免费的小型项目 CI 服务器，例如 TeamCity）
2) 具有 1. 准备能够针对您的三个环境中的任何一个的部署过程
3) 考虑始终检查用户是否可以访问没有 .svn 文件在部署的站点上，因为它确实不安全
另请阅读有关在 SVN 中使用标签/分支的内容
接下来，我会建议以下工作流程
第一种情况（简单）
每个人都进行结帐并在本地副本上工作。
提交（经过充分测试）一定数量的新功能后，您的触发器（可能自动）预览将被构建
全面测试预览后，您可以触发构建生产
第二种情况（更好）
每个人都会对每一个大量的更改创建一个分支，并且可以自由地将任何内容提交到自己的分支。
拥有分支稳定分支后，您将其合并到主干，这会触发测试机检出并构建您命名的预览并标记标签
全面测试的预览版去发布分支
拥有这么多分支的要点是能够同时存储个人更改历史和稳定版本。
1) Look into conception of Continuous Integration. (there are a dozen free for small projects CI servers , for instance TeamCity)
2) Having 1. Prepare deployment procedure that will be able to target any of your three environments
3) Consider ALWAYS check that there is no .svn files accessible to users on deployed sited, because it is really unsecure
Also read something on working with tags/branches in SVN
Next, I would propose the following workflow
First case (simple)
Everyone makes checkout and works on local copy.
Having commited (well tested) amount of new functional, your trigger (maybe automatically) preview to be build
Having preview comprehensively tested, you trigger building production
Second case (better)
Everyone makes a branch on every considerable amount of changes and is free to comit anything to his own branch.
After having branch stable branch, you merge it to trunk what triggers test machine to checkout and build what you name preview and mark a tag
Comprehensively tested preview goes to release branch
Point to have so many branches is to be able to store personal changes history and stable builds at once.
您不想使用存储库的根目录作为工作副本的根目录。这使得以后不可能真正使用分支。 （或者你总是在本地检查所有分支。制作 Subversion 的廉价副本，而工作副本则昂贵）
You don't want to use the root of your repository as the root of your working copy. That makes it impossible to really use branches later. (Or you would alsways have all branches checked out locally.. making Subversion's cheap copies, expensive in the working copy)