开发者

Web Application deployment and database/runtime data management

开发者 https://www.devze.com 2023-02-14 19:51 出处:网络
I have decided to finally nail down my team\'s deployment processes, soup-to-nuts. The last remaining pain point for us is managing database and runtime data migration/management. Here are two example

I have decided to finally nail down my team's deployment processes, soup-to-nuts. The last remaining pain point for us is managing database and runtime data migration/management. Here are two examples, though many exist:

  • If releasing a new "Upload" feature, automatically create upload directory and configure permisions. In later releases, verify existence/permissions - forever, automatically.
  • If a value in the database (let's say an Account Status of "Sig开发者_运维知识库nup") is no longer valid, automatically migrate data in database to proper values, given some set of business rules.

I am interested in implementing a framework that allows developers to manage and deploy these changes with the same ease that we manage and deploy our code.

So the first question is: 1. What tools/frameworks are out there that provide this capacity?

In general, this seems to be an issue in any given language and platform. In my specific case, I am deploying a .NET MVC2 application which uses Fluent NHibernate for database abstraction. I already have in my deployment process a tool which triggers NHibernate's SchemaUpdate - which is awesome.

What I have built up to address this issue in my own way, is a tool that will scan target assemblies for classes which inherit from a certain abstract class (Deployment). That abstract class exposes hooks which you can override and implement your own arbitrary deployment code - in the context of your application's codebase. the Deployment class also provides for a versioning mechanism and the tool manages the current "deployment version" of a given running app. Then, a custom NAnt task glues this together with the NAnt deployment script, triggering the hooks at the appropriate times.

This seems to work well, and does meet my goals - but here's my beef, and leads to my second question: 2. Surely what I just wrote has to already exist. If so, can you point me to it? and 3. Has anyone started down this path and have insight into problems with this approach?

Lastly, if something like this exists, but not on the .NET platform, please still let me know - as I would be more interested in porting a known solution than starting from zero on my own solution.

Thanks everyone, I really appreciate your feedback!


Each major release, have a script to create the environment with the exact requirements you need.

For minor releases, have a script that is split into the various releases and incrementally alters the environment. There are some big benefits to this

  1. You can look at the changes to the environment over time by reading the script and matching it with release notes and change logs.
  2. You can create a brand new environment by running the latest major and then latest minor scripts.
  3. You can create a brand new environment of a previous version (perhaps for testing purposes) by specifying it to stop at a certain minor release.
0

精彩评论

暂无评论...
验证码 换一张
取 消