Document cfmigration strategies

[elpete]

Hi Eric Peterson,

Making this a QB issue since cfmigrations doesn't have a project (and it involves SchemaBuilder).

It looks like the way that cfmigrations was designed, it's primarily intended to be used by commandbox-cfmigrations. This is real easy to do on dev but I was thinking about how to build it into our deployment process. The first thing I tried was to just use cfmigrations (not commandbox-cfmigrations) and put a "migrate up" real early in our Application init. The trouble with this is that, if you use CFORM, it has to happen prior even to CFORM loading, or else any changes you've made to your ORM entities will throw errors since the DB won't have the migration yet. IIRC, there is a way to tell CF to ignore ORM errors when scanning CFCs, but I don't remember what it is and I'm not sure if it's sufficient here since we'd probably have to do an ORMReload() afterwards to re-scan it and that may not be desirable.

At any rate, you can't run cfmigrations that early in the app lifecycle because you don't have wirebox so cfmigrations can't get hold of SchemaBuilder. Presumably one could just create a SchemaBuilder without wirebox and give it all the necessary params; this doesn't seem too hard.

The alternative is to just have Commandbox run "migrate up" prior to starting the server. The path of least resistance here on a Docker deployment would seem to be editing the run.sh file that kicks off start-server.sh to add "migrate up" in there. The only drawback here is that you have to re-launch the whole container to run a migration, as opposed to the app lifecycle solution where you can do it at any time. This isn't a big drawback, especially since with ORM reloads you'd probably want a new container anyway.

Are these both (in your view) valid approaches to migration deployment?