Approaches to making changes to Production systems using Castle 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 aw开发者_运维知识库are 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 : )

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:

• Development
• Testing
• Staging
• Production

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.