如何发布Web应用程序？
我真的不知道如何在Web开发中正确执行从离线开发到实时Web服务器的部署。 我主要依靠直觉，但这或多或少是我到目前为止所做的：我有一个 python 或 php 的 Web 应用程序，我将它托管在实时网络服务器上。 我用的是离线开发版本，源码在svn下。
现在，当我开发离线版本时，我将执行对 svn 的提交。 当发布时间到来时，我可以：
- 将代码从离线服务器复制到实时网络服务器上的临时目录，然后将旧代码库与新代码库交换（例如，使用链接），或者
- ...实时网络服务器在结账 svn 上工作，只需运行 svn update 即可。
我通常会执行第二个操作，尽管如果我必须在实时部署之前升级数据库，我通常会编写升级 sql 脚本，并首先在实时数据库上运行它们，然后结帐。
这项任务的最佳实践是什么？
I don't really know how to perform deployment from offline development to live webserver correctly in web development. I mostly resort on intuition, but this is more or less what I did until now: I have a web application in python, or php, and I am hosting it on a live webserver. I use an offline development version whose source is under svn.
Now, as I develop the offline version, I will perform commits to the svn. When time has come for release, I could either:
- copy the code from the offline server to a temporary directory on the live webserver, then swap the old codebase with the new one (eg. with a link), or...
- have the live webserver work on a checkout svn, and just run svn update.
I normally do the second, although if I have to upgrade the database before the live deployment, I normally write upgrade sql scripts, and run them first on the live database, then checkout.
What are the best practices for this task ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我建议利用 SVN 导出而不是结账。 这样，您就不会向外界公开任何 SVN 文件。 它通常还会创建更清晰的文件夹结构。
我之前在阶段和生产之间移动文件时利用过 rsync。
我的典型部署过程如下：
现在，要部署到生产环境，请快进重播这些步骤。 使用脚本使其变得更加容易。
I recommend leveraging SVN export instead of checkout. This way, you will not expose any of the SVN files to the world. It also generally creates a cleaner folder structure.
I have leveraged rsync before when moving files between stage and production.
My typical deployment proceeds as follows:
Now, to deploy to production, replay these steps in fast forward. Using scripts make it much easier.
您应该考虑一些部署脚本来自动化这一切。 这将有助于防止你犯错误。 SQL 升级脚本是一种生活方式，但您应该始终在实时数据库的副本上测试它们，然后再在真实数据库上运行它们。
您可能会考虑拥有一台临时服务器。 您进行本地更改，然后 svn checkout 到临时服务器并在那里运行升级脚本。 您在登台服务器上进行验收测试。 当一切顺利时，您可以将所有内容部署到实时服务器。 这应该像运行一些脚本一样简单。 即 update-staging.pl 和 update-prod.pl。
您可以通过向数据库添加版本表来使您的 sql 脚本更容易自动化。 每当您创建更新脚本时，都会用版本标记它。 然后部署脚本可以查看更新脚本的版本和数据库的版本，并根据需要应用更新。 这也使得从备份恢复变得可行。 如果您进行了更改，然后恢复到备份，您只需运行升级脚本，它就会将数据库更新到当前版本。
You should consider some deployment scripts to automate all this. it will help prevent you from making mistakes. SQL upgrade scripts are a way of life, but you should always test them on a copy of the live database before you run them on them on the real one.
What you might consider having is a staging server. You do your local changes, then svn checkout to the staging server and run your upgrade scripts there as well. You do your acceptance test on the staging server. When everything is good, you deploy everhting to the live server. This should be as simple as running some scripts. i.e. update-staging.pl and update-prod.pl.
You can make your sql script easier to automate by adding a version table to your db. whenever you create an update script, you tag it with a version. then the deployment script can look at the version of your update script, and the version of the database and apply the updates as needed. this also makes restoring from backups feasible. If you have made changes, then restore to a backup, you just run your upgrade script and it goes through and updates the db to the current version.
我使用 Capistrano 来编写脚本和 自动化部署过程。 以下是当我从本地工作站输入
cap deploy时发生的情况的概述：Capistrano 将会发生。 。 。
在我的网络服务器上的带时间戳的目录（例如
/var/http/mywebsite.com/releases/20090715014527）中签出最新版本的源代码，提示我@我的本地工作站输入任何密码，如有必要。运行预处理脚本（例如更新数据库架构）
将站点软链接到实时目录：
ln -sf /var/http/mywebsite.com/releases/20090715014527 /var/http/mywebsite.com/current
运行后处理脚本（例如，也许您需要重新启动apache或其他东西）
如果在此过程中出现任何问题，Capistrano 将回滚到之前的工作版本。
尽管 Capistrano 是用 Ruby 编写的，但它可以用任何语言/框架部署 Web 应用程序。 请参阅教程的“部署非 Rails 应用程序”部分了解想法。 railsless-deploy 似乎对于使用 Capistrano 管理 PHP 和 Python 的部署特别有用应用。
I use Capistrano to script & automate the deployment process. Here's an outline of what happens when I enter
cap deployfrom my local workstation:Capistrano will. . .
Checkout latest version of source in a time-stamped directory (e.g. to
/var/http/mywebsite.com/releases/20090715014527) on my webserver, prompting me @ my local workstation for any passwords, if necessary.Run pre-processing scripts (e.g. update database schema)
Soft link the site to a live directory:
ln -sf /var/http/mywebsite.com/releases/20090715014527 /var/http/mywebsite.com/current
Run post-processing scripts (e.g. maybe you need to restart apache or something)
If there were any problems along the way, Capistrano will rollback to the previous working release.
Although Capistrano is written in Ruby, it can deploy web applications in any language/framework. See the "Deploying non-rails apps" section of the tutorials for ideas. The railsless-deploy seems particularly useful for using Capistrano to manage deploying PHP and Python apps.
理论上我会将 svn 导出到网络服务器上的新区域。 然后重新配置网络服务器以使用新区域并重新启动。
In theory I would export the svn to a new area on webserver. Then reconfigure the webserver to use new area and restart.
对于小型的、基于 php 的系统，我们过去常常这样做：
对于代码更改，我们使用从 eclipse 运行的 ant 脚本，该脚本将本地（dev）系统与远程（qa/prod/whatever）系统进行比较，然后压缩所有更改的文件，将 zip 文件 scp 到远程系统并将其解压缩到目标上。 当然我们还有自动备份之类的。 如果对此感兴趣，我将能够在接下来的几天内发布示例脚本。
对于 sql 更改，我们尝试为每个更改维护一个脚本（通常在我们的错误跟踪器中）并在目标系统上手动运行每个更改。
对于大型系统，您确实应该使用更强大的东西。
请注意，如果您的 prod 系统直接从 svn 拉取，那么您正在部署可能尚未正确测试的更改（您可能忘记提交某些内容，测试本地系统，并且 prod 中的所有内容都会中断...）
for small, php-based systems, what we used to do is this:
for code changes, we use an ant script running from eclipse that compares the local (dev) system with the remote (qa/prod/whatever) systems, then zips all the changed files, scp the zip to the remote system and unzip it on the target. Of course we have automated backup and the like. If this is of interest I would be able to post an example script in the next few days.
for sql changes, we try to maintain a scripts for each change (usually in our bug-tracker) and manually run each change on the target system.
for large systems you shoudl really use something more robust.
note that if your prod system is pulling directly from svn then you are deplolying changes that might have not been tested properly (you might forget to commit something, test you local system, and everything would break in prod...)
我会推荐第一个选项。 如果你有一个结构，你可以放置代码的版本并通过更改链接在它们之间切换，那么回滚比你只有一个 svn checkout 容易得多。 使用 svn 你必须与以前的版本合并才能恢复。
I would recommend the first option. If you have a structure where you can put versions of the code and flip between them by changing a link, it is much easier to roll back than if you just have an svn checkout. With svn you have to merge with a previous version to revert.