从版本控制部署网站 - 导出和符号链接？
我是一个孤独的开发者。我们有几个网站托管在网络主机上。 svn 存储库也在 Web 主机上。在内部，我们有一台开发机器，它是实时环境的足够接近的复制。
对于实时网站，我有一个来自 subversion 的导出，并用版本号适当命名。实时网站的文档根实际上是该目录的符号链接。这样，我只需更改符号链接指向的位置，就可以轻松地回滚到导出版本，而无需停机。
当实际部署时，我会将主干的一个版本导出到实时网站的子目录中，作为暂存区，并进行一些测试。这样我就可以看到它在实时环境中的实际行为，而无需更改用户看到的任何内容。然后，如果一切看起来都正常，我将再次导出到我的帐户根目录并更改符号链接（并再次测试！）
这是否太过分了？还有哪些其他方法可以做到这一点？
I am a lone developer. We have a couple of websites hosted on a web host. The svn repository is also on the web host. In house, we have a development machine, which is a close-enough replication of the live environment.
For the live website, I have an export from subversion, appropriately named with the version number. The live website's document root is actually a symlink to that directory. That way, I can easily roll back or forth to exported versions with no downtime simply by changing where the symlink is pointed.
When it comes time to actually deploy, I will export a version of the trunk to a subdirectory of the live website, as a staging area, and do some testing. That way I see how it actually behaves in the live environment, without changing anything that users see. Then if everything looks okay, I'll do another export to the my account root and change the symlink ( and test again! )
Is this overdoing it? What are other ways of doing it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Capistrano 可以帮助您完成此过程。使用 SSH 和密钥，可以使部署更改等过程变得非常无缝。虽然这是一个 ruby 应用程序，但您仍然可以使用它来部署 PHP 或其他应用程序，请查看 这里获取一些信息
本文讨论了它，使用共享文件夹和发布文件夹。共享文件夹可以保存您个人部署服务器的配置文件（URL、数据库连接等）以及在网站生命周期内上传且不在 svn 中的资产。您也可以让 Capistrano 为您处理这个问题。
虽然不了解设置的人第一次看到这一点可能会有点困难，但它确实使部署变得容易。我认为 Capistrano 所做的非常简单，可能可以用另一种语言编写来处理您的特定场景。
还有一个想法是将其与 SVN 或任何存储库联系起来。就是利用他们的钩子来执行这些部署。即每次提交到主干都会更新开发服务器。一个分支会将其推送到您的暂存环境。
但是此链接做得很好展示如何设置这种类型的环境。我认为你所建立的做法是很好的做法，但做得还不够。唯一可以帮助您的是自动部署到不同的环境和脚本，以帮助您设置新的部署。
更新::
另外，我想指出，SVN 可以处理符号链接。因此，如果您在基于 Unix 的服务器上进行部署，您只需将符号链接放入存储库中并使用相对符号链接即可。
因此，如果您有，
您可以将符号链接设置为
这将为您提供一种简单的方法来管理不在 svn 中的资产，而无需使用大量脚本进行部署。您现在可以使用提交来部署到您的开发和/或暂存。
There is Capistrano, which helps you in this process. Using SSH and keys, it makes the process pretty seamless to deploy changes and such. While this is a ruby app, you can use it still to deploy PHP or other applications, take a look here for some info
And this article talks about it, using a shared folder along with your release folder. The shared folder can hold config files for your individual deployment server (URL, DB connection, etc) as well as assets that are uploaded during the life of a website and aren't in svn. You can have Capistrano handle this for you also.
While someone not knowing the setup might have a bit of difficulty first seeing this, it really makes deployment easy. I think what Capistrano does is pretty simple and could probably be written in another language to handle your specific scenario.
And another idea to tie this into SVN, or any repository. Is to use their hooks to execute these deployments. i.e. every commit to trunk will update the dev server. And a branch will push it to your staging environment.
But this link does a great job of showing how to set up that type of environment. I think what you have set up is good practice and isn't done enough. The only thing that can help you out is automated deployment to different environments and scripts to help with the setup of your new deployment.
Update ::
Also, I'd like to note, SVN can handle symlinks. So if you are doing deployments on Unix based servers you can just put in the symlinks in your repository and use a relative symlink.
So if you have
You can put your symlink as
This will give you an easy way to manage assets not in svn without using a lot of scripts do deploy. You can now just use a commit to deploy to your dev and/or staging.
我认为这正是正确的做法。对我来说看起来很理想：实时更新是经过全面测试的版本，更改可以通过提交消息很好地记录下来，回滚（来回）很容易，并且从一个版本到另一个版本的切换是原子的，因此没有停机时间。我努力以同样的方式对待每个项目。
你的问题是什么？您对某事不确定吗？这不适合你吗？如果是这样，具体是哪一部分？
I think this is exactly the right way of doing it. Looks ideal to me: Live updates come as a fully tested release, changes are well documentable through commit messages, rolling back (and forth) is easy and the switch from one version to another is atomic so there is no downtime. I strive to do it the same way with every project.
What is your question? Are you unsure about something? Is it not working out for you? If so, what part of it exactly?
这就是我在过去几年里为几个项目所做的事情——而且这种做事方式从来没有遇到过任何问题。
使用符号链接进行“回滚”的可能性可能会被视为有点矫枉过正，是的......但是当您需要它来保存部署了具有严重错误的版本的网站的那一天，您真的很感激拥有这种能力！
我在 3 年内使用过这个东西 2 次——但是，每一次，它都确实挽救了这一天 ^^
不过，有一件事对我来说似乎很奇怪：如果我理解正确的话，您正在实时（生产）数据库上测试网站的新版本吗？
如果是这样，如果应用程序中存在错误，您可能会破坏您的生产数据库——这显然会很糟糕。
我个人会为该测试环境使用另一个数据库——只是作为一种安全措施。
另外：你正在做很多测试，这很好......但为什么不自动化其中一些呢？
它可以让您更快、更频繁地进行测试，并且您可以花更少的时间进行测试，而将更多的时间用于开发;-)
It's kind of what I've doing for the last couple of year for a couple of projects -- and never had a single problem with that way of doing things.
The possibility of "rollback" with the symlinks might be seen as a bit overkill, yes... But the day you need it to save the website on which you deployed a version with a critical bug, you really appreciate having that ability !
I've used this something like 2 times in 3 years -- but, each time, it really saved the day ^^
One thing seems odd to me, though : if I understand correctly, you are testing the new version of the website on the live (production) database ?
If so, if there is a bug in the application, you could destroy your production database -- which, obviously, would be bad.
I would use another database for that testing environment, personnaly -- just as a security measure.
Also : you are doing a lot of tests, which is good... But why not automate some of those ?
It would allow you to test faster, more often, and you'd spend less time testing, and more time developping ;-)