在生产环境中发布基于 python/ruby/script 的 Web 应用程序时的实践
我是一个纯粹的 Windows 程序员，所有的时间都花在了 VC++ 上。
最近，我一直在领导几个基于 Web 的应用程序，我自己用 python（/pylons 框架）构建了应用程序，并在 Rails 上做项目。所有 Web 项目都托管在 ubuntu Linux 上。
当涉及到基于脚本的语言时，我们用于构建和发布 VC++ Windows 应用程序所遵循的发布过程和检查表仅仅不再有用。
所以我们现在不构建任何二进制文件。我在使用开源cms应用程序时通过ftp服务器将asp/php文件复制到IIS文件夹中。
因此FTP是将文件托管到Web服务器的方式之一。现在，我们懒惰或不那么热衷于通过 ftp 复制文件，而是使用 SVN checkout，并且只需执行 svn update 即可获取最新副本。
SVN checkout 和 svn update 是将最新构建文件更新到服务器的正确方法吗？使用 svn update 有什么缺点吗？有更好的方法将脚本/基于 Web 的脚本发布到生产服务器中吗？
PS：我在linux平台上的一些扩展中使用了ssh服务器。
I am purely a windows programmer and spend all my time hacking VC++.
Recently I have been heading several web based applications and myself built applications with python (/pylons framework) and doing projects on rails. All the web projects are hosted on ubuntu linux.
The RELEASE procedures and check list we followed for building and releasing VC++ windows application are merely no more useful when it comes to script based language.
So we don't built any binaries now. I copied asp/php files into IIS folder through ftp server when using open source cms applications.
So FTP is the one of the way to host the files to the web server. Now we feel lazy or not so passionate to copy files via ftp instead we use the SVN checkout and we simply do svn update to get the latest copy.
Is SVN checkout and svn update are the right methods to update the latest build files into the server? Are there any downside in using svn update? Any better method to release the script/web based scripts into the production server?
PS: I have used ssh server at some extension on linux platform.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我会在 SVN 中为 Web 应用程序的每个版本创建一个分支，当该版本准备就绪时，我会在服务器上检查它并设置为运行或将其移动到旧版本的位置。
I would create a branch in SVN for every release of web application and when the release is ready there, I would check it out on the server and set to be run or move it into the place of the old version.
SVN checkout 和 svn update 是将最新构建文件更新到服务器的正确方法吗？
非常非常好的方法。你知道你得到了什么。你可以随时向后退。
使用 svn update 有什么缺点吗？没有任何。
有更好的方法将脚本/基于 Web 的脚本发布到生产服务器中吗？
我们做什么。
我们不会用完 SVN 签出目录。 SVN 签出目录是位于服务器上的“原始”源。
我们使用Python的
setup.py install在/opt/app/app-xy目录树中创建应用程序。每个标记的 SVN 分支也是最终安装中的一个分支。Ruby 有 gems 和其他可能与 Python 类似的安装工具。
我们网站的 Apache 和 mod_wsgi 配置引用特定的
/opt/app/app-xy版本。然后，我们可以暂存一个版本，进行测试，执行诸如将数据从生产迁移到下一个版本之类的操作，并做好总体准备。然后我们调整 Apache 和 mod_wsgi 配置以使用下一个版本。
以前的版本都已经到位了。并留在原地。有一天，当它们让我们感到困惑时，我们会删除它们。
Is SVN checkout and svn update are the right methods to update the latest build files into the server?
Very, very good methods. You know what you got. You can go backwards at any time.
Are there any downside in using svn update? None.
Any better method to release the script/web based scripts into the production server?
What we do.
We do not run out of the SVN checkout directories. The SVN checkout directory is "raw" source sitting on the server.
We use Python's
setup.py installto create the application in/opt/app/app-x.ydirectory tree. Each tagged SVN branch is also a branch in the final installation.Ruby has gems and other installation tools that are probably similar to Python's.
Our web site's Apache and mod_wsgi configurations refer to a specific
/opt/app/app-x.yversion. We can then stage a version, do testing, do things like migrate data from production to the next release, and generally get ready.Then we adjust our Apache and mod_wsgi configuration to use the next version.
Previous versions are all in place. And left in place. We'll delete them some day when they confuse us.
在 Web 根目录上进行 svn 更新的一个缺点是 .svn 目录可能会被公开，因此 注意网络服务器上的权限。
也就是说，有更好的方法来部署使用动态语言构建的应用程序。在 Rails 世界中 Capistrano 是一个成熟的部署工具，Vlad 部署者。 Capistrano 可以轻松用于非rails部署
基于版本控制的部署策略有很多。您可以阅读教程并获得一些想法。
我还想补充一点，即使我们不使用动态语言“构建”（编译）项目，我们也会“构建”（测试/集成）它们。一个严肃的项目将使用持续集成服务器来验证每个项目上的集成“构建”在投入生产之前就进行提交或集成。
The one downside of doing an svn update on your web root is that the .svn directories can potentially be made public, so be careful about permissions on the web server.
That said, there are far better ways to deploy an app built with dynamic languages. In the Rails world Capistrano is a mature deployment tool, as well as Vlad the Deployer. Capistrano can easily be used for non-rails deployments
There are many deployment strategies based on version control. You could go through the tutorials and get some ideas.
I'd also like to add that even though we do not "build" (compile) the project in dynamic languages, we do "build" (test/integration) them. A serious project would use a continuous integration server to validate the integrated "build" of project on every commit or integration, well before it gets to production.
进行 svn 更新的一个缺点是：虽然你可以回到过去，但你会回到哪个版本？你必须查一下。如果您使用标签，svn update 伪部署会工作得更干净 - 在这种情况下，您将执行 svn 切换到不同的标签，而不是在同一分支或主干上进行 svn update。
您希望使用版本号（例如 1.1.4 ）标记您的软件，然后使用一个简单的脚本将其压缩 application-1.1.4,zip 并部署它 - 然后您就可以自动进行可重复的发布和回滚以及更大的功能了解版本之间的变化。
One downside of doing an svn update: though you can go back in time, to what revision do you go back to? You have to look it up. svn update pseudo-deployments work much cleaner if you use tags - in that case you'd be doing an svn switch to a different tag, not an svn update on the same branch or the trunk.
You want to tag your software with the version number something like 1.1.4 , and then have a simple script to zip it up application-1.1.4,zip, and deploy it - then you have automated repeatable releases and rollbacks as well as greater visibility into what is changing between releases.