使用 Castle ActiveRecord 更改生产系统的方法
我观看了 Castle ActiveRecord 的一些演示，并且很喜欢构建原型应用程序的速度，但我担心一旦您的生产系统运行起来它会有多大用处。
理想情况下，如果或当我必须对系统进行更改时，我可以以相同的方式继续开发，即不真正关心与数据库的交互，这对我来说将是一个梦想。
但是，我知道在某些情况下，您可能会发现自己在 ActiveRecord 之外进行数据库调整，如果您让 ActiveRecord 尝试更新您的架构，您可能会丢失或可能出错。
是否有人使用 ActiveRecord（或类似的），而不仅仅是原型设计，实际上是在维护和附加功能中，如果是的话，您的工作流程是什么样的？
我的预期用途是一个多商店、多语言的电子商务解决方案。不是最复杂的应用程序，但也不是最简单的！
萨姆:)
I've watched a few demos of Castle ActiveRecord and love how quickly you can build up a prototype application but am concerned about how useful it would be once you have your production system running.
Ideally, if or when i have to make changes to the system I could carry on developing in the same manner, ie.not really concerning myself with interacting with the database, that would be a dream for me.
However, Im aware that there may be situations where you find yourself making db adjustments outside of ActiveRecord that you would then lose or possibly error if you let ActiveRecord attempt to update your schema.
Is anybody using ActiveRecord (or similar) beyond just prototyping and actually in maintainance and additional features, and if so whats your workflow like??!
My intended usage for this will be a multi-store, multi-language e-commerce solution. Not the most complicated application but also not the simplest!
Sam : )
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们将 Castle ActiveRecord 用于我们在这里编写的 ASP.NET MVC 3 应用程序。我可以告诉您应用程序投入生产后（几周后）我们计划做什么。
我们有一个四阶段环境：
我们使用 Git 进行源代码控制，使用 Jenkins 进行持续集成。应用程序设置为在开发计算机每次运行时自动删除/重新创建数据库（例如使用 Visual Studio 2010）；我们有一个开发机器列表，应用程序检查当前正在运行的机器以查看是否应该删除/创建数据库。
当我们将 Git 中的更改推送到中央（裸）存储库时，Jenkins 会（通过轮询）检测到更改。它构建应用程序、运行测试、将应用程序部署到我们的开发 Web 服务器上，并在我们的开发 SQL Server 实例上删除/重新创建架构和测试数据。
但这仅适用于开发，其中快速原型制作很重要。对于其他三个环境的部署，我们计划为我们的服务器/基础设施组提供他们可以运行的打包部署文件。对于数据库部分，我们的数据库组将使用 Red Gate 的比较工具来比较环境与其前身环境之间的架构，并在必要时进行更新。因此，开发中的模式更改被“比较和更新”到测试，然后测试到阶段，等等。
这使得这些部署不太自动化，但它确保我们不会影响这些环境中的数据。
We're using Castle ActiveRecord for an ASP.NET MVC 3 application we're writing here. I can tell you what we plan to do once the application is in production (in a few weeks).
We have a four-stage environment:
We use Git for source control and Jenkins for continuous integration. The application is set to automatically drop/recreate the database on each run for a development machine (e.g. using Visual Studio 2010); we have a list of development machines, and the app checks the currently running machine to see if it should drop/create the database.
When we push changes in Git to the central (bare) repository, Jenkins detects the changes (by polling). It builds the app, runs the tests, deploys the app onto our Development web server, and drops/re-creates the schema and test data on our Development SQL Server instance.
But that's only for development, where the rapid prototyping is important. For deployments to the other three environments, we plan to give our server/infrastructure group a packaged deployment file they can run. For the database portion, our database group will use Red Gate's compare tool to compare the schema between an environment and its predecessor environment and update where necessary. Thus schema changes from development are "compared and updated forward" to test, and test to stage, and so forth.
This leaves those deployments less than automatic, but it ensures that we don't affect data in those environments.