Jump to content
bernhard

[alpha] RockMigrations - Easy migrations from dev/staging to live server

Recommended Posts

Why Migrations?

Benjamin Milde wrote a great blog post about that: https://processwire.com/blog/posts/introduction-migrations-module/

Why another migrations module?

Benjamin's Migrations Module is great (https://modules.processwire.com/modules/migrations/), but there were two things that I didn't like:

  • For me, it didn't feel easy to use
  • You have to define Migrations in a central place and I wanted to be able to use Migrations in my Modules

The second point does bring downsides with it, so this might have been intended by him. Anyhow - I like when things work "my way" 🙂

Example

See this example of how it works and how easy it is to use. Let's start with a very simple Migration that only creates (on upgrade) or deletes (on downgrade) one field:

$upgrade = function(RockMigrations $rm) {
  $rm->createField('yournewfield', 'text');
};

$downgrade = function(RockMigrations $rm) {
  $rm->deleteField('yournewfield');
};

--------

I have to leave, but want to share my Migrations module with you. It's alpha and you have to make sure to have backups!! But I'm using it since several weeks now and it's a joy so far. Please see the detailed readme files and this screencast:

https://github.com/BernhardBaumrock/RockMigrations

Sorry, I'm in a hurry and have to leave, but I'm happy to hear your thoughts! 🙂 

  • Like 15

Share this post


Link to post
Share on other sites
2 hours ago, bernhard said:

Sorry, I'm in a hurry and have to leave, but I'm happy to hear your thoughts! 🙂 

I like the productivity of this lazy man who is in a hurry 😀!  You are on fire mate! 👍.

  • Haha 3

Share this post


Link to post
Share on other sites
19 hours ago, bernhard said:

The second point does bring downsides with it, so this might have been intended by him.

Quite correct 🙂 Migrations are supposed to be immutable files, so running them always yields the same effects. This is best accomplished if those migrations are managed in one central place by the entity affected. Nothing outside should implicitly be able to affect what migrations do. Having migrations in modules however does exactly that. If you update a module the migrations in it might be updated, which is not good (it might have already been executed in prod with the old code and later migrations depending on the new code might fail). Even having immutable migrations in the module might quickly become a burden as each new user must be moved through all „mistakes“ and „changes“ as well before being migrated to a final state needed by the most current version.

While I‘ve talked a bit about the mentioned downsides I also think modules should come with migrations, but in a different form. There should be generators, which generate migrations in the central migrations folder of the site using the module. They imho should always just generate the most recent version of migration needed. If a module does change the way to update old clients should be by having migrations to update from e.g. V1->V2. Those could be put in another generator or even just be put into a changelog. New users of a module wouldn‘t need to care about it, they directly get migrations generated for V2, existing users can leave their existing migration for V1 in their system and just add the update migration for V1->V2.

This way one can have the benefits of modules supplying migrations to users, while not having the downsides and a imo simpler option for not needing to keep track of all the old stuff already changed till eternity, especially for new users, which really don‘t need to care about old versions.

One last benefit of generation of code is that it‘s editable by the user. Like I could add localized labels to a field generated for a certain module, without any extra effort needed by the module creator. Another example might be adding additional fields to a template a module uses/creates, which might be needed just on the single site. This is also a downside, as editing could break the functionality, but I think it’s a quite clear danger and one can always generate the file(s) again to get to a working migration. 

Edit:
One last point. Migrations in modules like they're intended by @bernhard can work as well. I hope it's clear that most issues I pointed out above are about control, the one for the actual system using the migrations. I'm not keen on automatic stuff happening, which could break my system. Others might be happy to let module creators be in charge of not skrewing things up. On the other hand control means more responsibility, like changes in versions are a little bit more work for the module user.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Thx for clarifying.

I don't like the idea of code generators. Maybe because I'm not familiar with them. But I could think of some kind of central migrations queue system. Modules could "register" their migrations in a central place and make sure the order of execution is in a way that there are no conflicts. For example a migration could define

requires => ['otherModule' => '0.0.3']

This could then run the migration in "myModule", execute "otherModule" until v0.0.3 and continue with executing "myModule" migrations afterwards. At the moment this is a little theoretical, because I usually do small iterations, push them to production and for the next iteration I have to identical states to start from. That's easy to handle. Sometimes I even do changes by hand, if that is no problem (eg the change does not affect the live system - like changing a typo in some textfield or the like).

Also running a migration twice is usually not a problem at all. My api is designed in a way that, for example, if you create a field in your migration and the field already exists, it will just return that field. I'm not sure about this one. At the moment it feels like this is not the best idea, but I'm sure I've had a reason to do it this way 😄 It's alpha... things might change. I released it to get some feedback and input. And so far it did a great job on several updates across several sites 🙂 

Share this post


Link to post
Share on other sites
23 hours ago, bernhard said:

I don't like the idea of code generators. Maybe because I'm not familiar with them.

My migrations module has generators. Basically everything creating a migration file for you is one. Just that those are meant to be edited further, while files generated by modules would work as is.

Generally I think you‘re quite fine as you‘re doing modules and the sites using them by yourself. It‘s getting more complicated if things are no longer in one hand and happen independently from each other.

  • Like 1

Share this post


Link to post
Share on other sites

Not sure if anybody is already using it... I'm using it every day and I'm extending the api from time to time. Today I added a setFieldOrder() method. Now it is quite easy to change the order of fields and set new column widths:

// adjust field widths
$rm->setFieldData('project', ['columnWidth'=>33], 'rockinvoice');
$rm->setFieldData('inv_date', ['columnWidth'=>33], 'rockinvoice');
$rm->setFieldData('type', ['columnWidth'=>34], 'rockinvoice');

$rm->setFieldData('invoicetomarkup', ['columnWidth'=>100], 'rockinvoice');
$rm->setFieldData('due', ['columnWidth'=>25], 'rockinvoice');
$rm->setFieldData('paid', ['columnWidth'=>25], 'rockinvoice');
$rm->setFieldData('num', ['columnWidth'=>25], 'rockinvoice');
$rm->setFieldData('sap', ['columnWidth'=>25], 'rockinvoice');

$rm->setFieldOrder([
  'type',
  'invoicetomarkup',
  'due',
  'paid',
  'num',
  'sap',
], 'rockinvoice');

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...