使用网站的 SVN 进行开发和部署管理
一个网站的 Net 解决方案，由 5 个项目组成，有几个（不到 10 个）开发人员致力于该解决方案。我们几乎每天都会进行部署。 问题是，如何设置 SVN 存储库来支持这种情况（每日部署），还提到并非每个提交的文件都应该投入生产，部署之前有一个 QA 检查。
Net solution for a website, consisting of 5 projects, and there are a few(less than 10) developers working on the solution. We deploy almost on a daily basis.
The question is, how to setup the SVN repo to support this scenario (the daily deploy), also mentioning that not every commited file should go to production, there is a QA check before deploying.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尝试 TeamCity
（CI 工具），因为它对于少量 CI 是免费的。这可能比 CruiseControl.Net 更适合您，因为 CCNET 的配置非常繁重，因为它都是通过 XML 完成的。 TeamCity 使用向导创建脚本来管理版本，
如果您需要有关 CI 的任何其他帮助，请告诉我，因为这是我所热衷的。
Try out TeamCity
(CI tool) as its free for smaller amounts of CI. this may be better for you than CruiseControl.Net as CCNET is very configuration heavy as its all done via XML. TeamCity uses wizards to create the scripts to manage releases
if you need any other help on CI then let me know as its something I am evangelistic about.
您想要做的事情通常称为持续集成（CI ）。
虽然您可以使用 Subversion 来做到这一点，但它可能不是适合这项工作的工具。
有特殊的 CI 软件，它可以让您轻松地自动化必要的任务（从版本控制中签出、编译/构建、运行自动测试、部署等）。例如 CruiseControl.NET。
至于“并非每个提交的文件都应该投入生产”，常见的解决方案是有一个特殊的“发布”分支来部署。只有经过测试的代码才会合并到那里（或者让主干始终保持稳定，否则模型相同）。当然，您也可以（更好：另外）在自动部署之前进行测试，并且仅在所有测试通过后才进行部署。
使用发布分支
实际上，这意味着人们在生成代码时签入代码。有时此代码可以工作，有时则不能。当发布时间临近时，Subversion 中会创建一个“发布分支”。该发布分支实际上是源在分支时的冻结快照。现在这个分支可以用来编译&部署应用程序，然后可以对其进行测试。
没有新代码签入分支（但签入可以在其他地方继续）。仅当在分支中检测到错误时，才会签入分支来修复它。这一直持续到分支通过所有测试。然后该分支就可以作为软件的新版本发布；之后，只有在发布的版本需要修补时才会使用该分支。
当然，签入分支的任何错误修复也需要放入主干（通过合并分支 -> 主干，Subversion 对此提供特殊支持，或者通过在主干中重新实现修复，视情况而定）。
What you want to do is commonly referred to as Continuous integration (CI).
While you can do that using Subversion, it is probably not the right tool for the job.
There is special CI software, which will allow you to easily automate the necessary tasks (checkout from version control, compiling / building, running automatic tests, deployment etc). An example would be CruiseControl.NET.
As to "not every commited file should go to production", the common solution is to have a special "release" branch, which gets deployed. Only tested code is merged there (or have the trunk always be stable, otherwise same model). Of course, you can also (better: additionally) have tests before your automatic deployment, and only deploy if all tests pass.
Working with a release branch
In practice, this means that people check in their code as they produce it. Sometimes this code will work, sometimes not. When the release time draws nearer, a "release branch" is created in Subversion. This release branch is then effectively a frozen snapshot of the source as it was at the time of branching. Now this branch can be used to compile & deploy the application, which can then be tested.
No new code is checked into the branch (but checkins can continue elsewhere). Only if a bug is detected in the branch, will there be a checkin into the branch to fix it. This continues until the branch passes all tests. Then the branch can be released as a new version of the software; afterwards the branch will only be used if the released version needs to be patched.
Of course, any bugfixes checked into the branch need to also be put into the trunk (either by merging branch -> trunk, for which Subversion provides special support, or by reimplementing the fix in the trunk, as appropriate).