我现在正在为我的初创公司搭建开发环境。我使用 Hudson 来持续集成源代码。它每 10 分钟轮询 SVN 存储库是否有更改，如果有任何更改，则将其从我们的 DEV 服务器部署到 LIVE 服务器。
不过，我想要的是另一份 Hudson 工作，从 DEV 部署到 TEST。我希望能够将代码提交到 SVN，然后手动部署到 TEST，进行手动 QA 检查，然后将其转移到 LIVE。
有没有办法可以用 SVN 中的分支和主干来做到这一点？我希望它仍然每 10 分钟轮询一次，因为在很多情况下它应该直接从 DEV 进入 LIVE。我想也许我可以提交到一个分支，然后让 hudson 自动部署到 TEST，然后如果效果很好，则将分支提交到主干。我说得对吗？？
提前致谢
I am setting up the development environment for my start-up just now. I use Hudson for continuous integration of source code. It polls the SVN repository for changes every 10 minutes and if there are any deploys them to the LIVE servers from our DEV servers.
What I would like though is to have another Hudson job which deploys from DEV to TEST. I want to be able to commit code to SVN and then manually deploy to TEST, do a manual QA check and then it to be transferred to LIVE.
Is there a way I can do this with branches and the trunks in SVN? I would like it to still poll every 10 minutes as there are plenty of occasions when it should go straight from DEV to LIVE. I thought maybe I could commit to a branch then have hudson automate the deployment to TEST and then if it works out fine commit the branch to the trunk. Am I right??
Thanks in advance
发布评论
评论（2）
我不明白为什么你想要一个单独的测试步骤，如果仍然存在“很多情况下它应该直接从 DEV 到 LIVE”——正如 @Hightechrider 所说，这听起来很冒险。我的做法是：
如果您的手动测试在步骤 2 中失败，我假设您希望让开发人员修复代码并在部署到生产环境之前重复步骤 1 和 2。
我想知道我们是否误解了您的场景 - 如果是这样，请添加更多详细信息，说明为什么您有时想要部署到测试，有时想要直接部署到实时。
I don't understand why you want a separate test step if there are still "plenty of occasions when it should go straight from DEV to LIVE" - which, as @Hightechrider says, sounds risky. The way I would do it is:
If your manual tests fail in step 2, I'm assuming you'll want to have your developers fix the code and repeat steps 1 and 2 before deploying to production.
I'm wondering if we're misunderstanding your scenario - if so, please add some more details on why you sometimes want to deploy to TEST and other times straight to LIVE.
我们使用 TeamCity 所做的是构建二进制文件，然后将二进制文件签入到单独的 BINARY SVN 中，以便使用 SVN LOAD_DIRS 进行测试。将这些位部署到测试服务器。如果它们看起来不错，请手动启动另一个 CI 任务，该任务再次使用 SVN LOAD_DIRS 将这些位复制到生产 SVN 存储库，然后将这些位部署到生产环境。
这样做的优点是，您拥有部署到每个服务器的确切位的副本，并且可以轻松回滚，或者可以查看任何特定版本（例如上周五的版本）并对其进行测试。您还可以对二进制版本中的配置文件进行更改，并将其部署到生产环境，同时仍然可以跟踪记录谁更改了什么以及何时更改。
这还为您提供了一个具有原子属性的部署系统 - 即，当您尝试将服务器更新到新版本时，您要么得到全部，要么什么也得不到，而永远不会出现部分/失败的部署。
另一个优点是，您可以通过仅检查那些单独更改的文件，将生产中的各个内容文件替换为最新版本 - 这是周五下午 4 点的一个方便功能，此时您不想冒险进行完整部署，以防万一发生其他更改到二进制文件中。
我看不到我们想要直接部署到 LIVE 的场景 - 听起来有风险。
What we do using TeamCity is to build and then check in the binaries to a separate BINARY SVN for TEST using SVN LOAD_DIRS. Deploy those bits to TEST servers. If they look good, fire off another CI task manually that uses SVN LOAD_DIRS a second time to copy the bits over to a PRODUCTION SVN repository and then deploy those bits to production.
The advantage of this is that you have a copy of the exact bits you deployed to each server and can roll back easily, or can check out any specific version (say, last friday's) and test against that. You can also make changes to configuration files in the binary version and deploy those to production whilst still having a track record of who changed what, and when they did it.
This also gives you a deployment system with atomic properties - i.e. you get all or nothing when you try to update your servers to the new version, and never a partial / failed deployment.
Another advantage is that you can surgically replace individual content files in production with the latest version by checking out just those individual changed files - a handy feature at 4PM on Friday when you'd rather not risk a full deployment just in case some other change sneaked in to the binaries.
I can't see a scenario where we would ever want a direct deployment to LIVE - sounds risky.