将 Web 应用程序从开发阶段转移到生产的最佳实践是什么？
我们的开发环境有很多层，有效复制甚至备份都很复杂。 基本上，文件系统（即 /usr/appdir/webapp...）还有其他应用程序为我们的 Web 应用程序提供服务，我们更新的这些应用程序从其存储库进行 svn 更新。
Web 应用程序本身（作为用户）的使用将影响文件系统和数据库。 因此，备份系统就是在同一时间点拥有文件系统和数据库（mysqldump）的副本。 两者之一本身并不是完整的备份，因为应用程序本身是非常动态的。
当我们将一个 Web 应用程序部署到暂存阶段以供一位客户测试和输入数据时，我们的环境现在很难从我们的开发环境同步回来，甚至很难将其投入生产。 由于我们会在开发过程中向客户提出变更请求，但客户本身会在暂存阶段进行变更。
目前我们正在使用冻结期，我们要求客户对开发环境甚至直接对生产环境进行更改（在完全上线之前）。
我想知道它们是否是关于如何从开发人员处传递有效流程的最佳实践 --> 分期--> 生产？ 或者如果您可能有一些指示。
Our Development environment has many layers and is complicated to replicate or even backup effectively. Basically the File system (ie. /usr/appdir/webapp...) has other applications serving our web application, those application we update doing svn updates from their repository.
The use of the web application itself (as a user) will affect both the file system and the database. So backing up the system is a matter of having a copy of both the file system and database (mysqldump) at the same point in time. One of the two by itself will not be a complete backup since the application is very dynamic itself.
When we deploy an webapp to staging for one of our customers to test and enter data, then we have an environment that now is difficult to sync back from our development environment, or even to take it to production. Since we will make change request from the customer in development, but the customer itself will make changes in staging.
At this moment we are using freezing periods, where we ask our customers to make changes to development environments or even directly to production (before going live completely).
I am wondering if their is a best practice on how to have a effective process to pass from dev --> staging --> production? Or if you might have some pointers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从听起来来看，您的问题因应用程序的性质而变得复杂。
首先，您的应用程序是否区分属于应用程序一部分的文件和仅作为数据的文件？ 如果不是，除非您有非常令人信服的理由不这样做，否则这种性质的改变应该使文件系统的版本控制变得更加简单 - 那么将应用程序部分置于版本控制之下是有意义的，而不是数据部分。
其次，我一直发现保持文件系统数据与数据库数据同步很痛苦。 一种解决方案（可能是更广泛的重构）是使一个解决方案可以从另一个解决方案生成。 您能否以某种方式将文件系统内容存储在链接到相关数据的数据库中，从而可以从脚本填充文件系统？ 如果您的文件太大，在许多情况下，用于开发和测试目的的代表性文件就足够了。
或者，您可以拥有一个单独的数据存储库，它可以拍摄一组数据（数据库和文件系统）的有效快照，这些数据可以与您的应用程序代码分开存储和管理（尽管这种方法会带来其他问题...... ）
如果这里的设计问题是不可改变的，我想不出比你的冻结期更好的主意了。
From the sound of it, your problem is complicated by the nature of your application.
Firstly, does your application make a distinction between files that are part of the application, and files that are mere data? If not, unless you have a very compelling reason for not doing so, a change of that nature should make version control of your filesystem much simpler - then it would make sense to have the application parts under version control, but not the data parts.
Secondly, I have always found keeping filesystem data in sync with database data a pain. One solution (which may be a more extensive refactoring) is to make one generate-able from the other. Could you somehow store the filesystem stuff in your database linked to the relevant data, that could populate the filesystem from a script? If your files are too big, in many cases having representative files for the purposes of development and testing will suffice.
Alternatively, you could have a separate repository for data, which can take a valid snapshot of a set of data (both database and filesystem) which can be stored and managed separately to your application code (although this approach will bring other problems...)
If the design issues here are immutable, I can't think of a better idea than your freezing periods.
我通常不会对 QA/暂存环境进行任何更改。 任何更改都会在开发环境中进行，然后推送到 QA/staging 和生产。 通常，如果可以避免的话，我也不会在 QA/staging 中使用实时数据。 如果我在 QA/staging 中确实有实时数据，我将使用 SQL Data Compare（来自 Red Gate）之类的工具来管理新数据从 QA/staging 环境到生产的迁移。
此外，我在源代码控制中维护开发/质量保证/生产的单独配置。 当更改影响所有配置时，必须记住对所有配置进行更改有点痛苦，但存在足够的差异，因此这样做比在应用程序发布/发布时更新 QA/生产配置更容易安装。
I typically don't make any changes in the QA/staging environment. Any change gets made in the development environment and then pushed to both QA/staging and production. Normally, I don't use live data in QA/staging either if I can avoid it. In cases where I do have live data in QA/staging, I'll use something like SQL Data Compare (from Red Gate) to manage the migration of new data from the QA/staging environment to production.
Also, I maintain separate configurations for dev/QA/production in source code control. It's a bit of a pain to have to remember to make changes in all configs when the change affects them all, but there are enough differences that it is easier to do this than to update the config for QA/production when the app gets published/installed.