将django应用程序从dev移动到prod时的常见错误？ [英] Common errors when moving a django app from dev to prod?

问题描述

我正在Windows，SQLite和django dev服务器上开发一个django应用程序。我已经将其部署到运行Linux，Apache，FastCgi，MySQL的主机服务器。

不幸的是，我的服务器在prod上返回的错误一切都ok在开机上。我要求我的提供商提供一个预生产解决方案，以便能够调试和了解问题。

无论如何，根据你最可能的错误将django应用程序从dev移动到prod时可能会发生这种情况？

最佳

更新：我认为预制是解决这种问题的最佳方法。但是，我想建立一个检查清单，以便在投产之前必须做些什么。
感谢直到现在收到的非常有价值的答案：）

更新：FYI，我已经实现了preprod服务器和电子邮件通知，如我可以看到错误来自我在此使用的 smart_if templatetag 新版本。任何模板标签的招数？

更新：我想我已经修复了由Filezilla FTP发送造成的pb。我正在使用替换如果更新选项，我猜是导致一些意想不到的结果。使用全部替换选项可以解决问题。但是，这是一次让我更多地了解部署的机会。 Thansk为您的答案。

解决方案

我通常会遇到的问题包括：

1. 配置不当的生产设置，无论是在我的生产中localsettings.py，wsgi / cgi还是/ etc / sites-available中的apache站点文件


2. 数据库差异。我使用 South 进行迁移，并在PostgreSQL上顺利执行迁移时遇到一些微妙的问题sqlite。


3. 静态文件托管，因为我在开发中欺骗和使用Django服务器


4. 文件系统和数据库中的权限
li>

5. 无论是PyPi还是第三方网站，罕见但可能的网络问题阻止我获得我的依赖关系

我已经减轻了这些问题的方法：

• 在生产和开发中使用相同的数据库（在您的情况下，MySQL无处不在）


• 我发现有一个测试环境以各种可能的方式模拟生产（它可以在低端硬件甚至是同一台机器上）是有用的。这样，如果在这个生产型环境中有任何问题，我可以在不使我的生产服务器脱机的情况下解决这些问题。


• 将所有内容都编写为可重复部署。我使用 fabric ，但是zc.buildout或Paver也可以工作。这些工具有助于减少部署时的拼写错误，并减少部署我的应用程序的时间。


• 使用版本控制（mercurial，git，subversion）和模式迁移工具（如南）在部署到生产时出错，您有可能退出更改，并允许使用旧数据库模式在旧代码上运行生产。


• 我还没有设置一个 egg proxy 但是我正在考虑它，以避免在下载依赖关系时出现问题。


• 我发现 pip的冻结依赖关系是有用的，万一从我下载最新的图书馆发生新的不兼容的更改


• 使用像Windmill或Selenium这样的Web测试框架，在我的测试环境中测试我的应用程序o我可以很快地得到我系统的很多测试报道。

I am developping a django app on Windows, SQLite and the django dev server . I have deployed it to my host server which is running Linux, Apache, FastCgi, MySQL.

Unfortunately, I have an error returned by the server on the prod while everything ok on the dev machine. I've asked my provider for a pre-production solution in order to be able to debug and understand the problem.

Anyway, what are according to you the most likely errors that can happen when moving a django app from dev to prod?

Best

Update: I think that a pre-prod is the best way to address this kind of problem. But I would like to build a check list of what must be done before to put in production. Thanks for the very valuable answers that I received until now :)

Update: FYI, I 've implemented the preprod server and the email notification as suggested by shanyu and I can see that the error comes from the smart_if templatetag that I am using on this new version. Any trick with template tags?

Update: I think I've fixed the pb which was caused I think by the Filezilla FTP sending. I was using the "replace if newer" option which I guess is causing some unexpected results. Using the "replace all" option fix the issue. However, it was an opportunity for me to learn more about deployment. Thansk for your answers.

解决方案

Problems I typically have include:

1. Misconfigured productions settings, whether in my production localsettings.py, wsgi/cgi, or apache site files in /etc/sites-available
2. Database differences. I use South for migrations and have run into some subtle issues when performing my migration on PostgreSQL when it worked smoothly in sqlite.
3. Static file hosting since I cheat and use the Django server in development
4. Permissions, both on the file system and within the database
5. Rare, but possible, network issues preventing me from getting my dependencies, whether on PyPi or some 3rd party site

Ways that I have mitigated these issues:

• Use the same database in production and development (in your case, MySQL everywhere)
• I've found it is useful to have a "test" environment which mimics production in every way possible (it can be on lower end hardware, or even the same machine). This way, if there are any issues in this "production-like" enivornment, I can solve them without taking my production server offline.
• Script everything for repeatable deployments. I use fabric, but zc.buildout or Paver would also work. These tools help reduce typos while deploying and reduce the time to deploy my app.
• Use version control (mercurial, git, subversion) and a schema migration tool (like South), so if something does go wrong when you deploy to production, you have the possibility of backing out the changes and allowing production to run on the old code with the old database schema.
• I haven't set up an "egg proxy" yet, but I am considering it, to avoid issues when downloading dependencies.
• I've found pip's freezing dependencies to be useful, in case a new, incompatible change to a library occurred since I downloaded it initially
• Use a web testing framework like Windmill or Selenium to test my application in my "test" environment, so that I can get a lot of test coverage of my system very quickly.

这篇关于将django应用程序从dev移动到prod时的常见错误？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！