[CRITIQUE REQUEST] Migration Practices

[eluser]WanWizard[/eluser]
@jmadsen,

I do all schema changes in migrations, including the initial creation of the database. If only because I don't want to look in two different places to find SQL that changes the DB schema.

@Lewis Cowles,

I don't know how you execute your development process, but in my company all dev's work from a local dev environment. I haven't got a clue what the state of the environment is of the guy sitting next to me. If he's working on a feature that requires an extra table, then he has it, but no one else does.

After development is complete my co-worker will push his changes to the repo, which gets auto-deployed to your staging environment. This will run the migrations after deployment so now staging has this new table too.

However, the feature hasn't been released to production, so the server running the production application is blissfully unaware there is a new table in the making. But when it passes staging, and needs to be deployed into production, I'm confident the new table will be created, thanks to the new migration file my co-worker has included.

If you don't have this mechanism, you have to manually make sure the database schema is in sync with the version of your code running. Not a pleasant idea...

[eluser]jmadsen[/eluser]
@Wanwizard - agree with you on all points, exactly why we started doing it that way, but...

Anyone make a script yet to convert sql to migration scripts? (maybe a task for me). Dreadfully dull & time consuming to build a large schema this way

[eluser]WanWizard[/eluser]
All you need is an up() and down() method.

What you put in it is entirely up to you, most of mine contain $this->db->query() calls with raw SQL instead of dbforge() calls with it's limitations.

[eluser]jmadsen[/eluser]
[quote author="WanWizard" date="1341237132"]All you need is an up() and down() method.

What you put in it is entirely up to you, most of mine contain $this->db->query() calls with raw SQL instead of dbforge() calls with it's limitations.[/quote]

perfect! That's again what we considered, but weren't sure if that would be a good practice (and to be honest, were running a bit behind schedule at that point)

I DO like the idea of migrations and am going to put a little more focus on using them from now on.

Thanks for your time!

[eluser]alexwenzel[/eluser]
Here i pasted a example migration. Just stumbled about this topic while working on migrations ^^

http://pastebin.com/1U0rGDmm