Should we add the migrations to the git repository

marco.kaiser

Today, we had a question and discussion here, about the adding of the migrations to the git repository.

Whats the statement of spryker or the other devs here?

src/Orm/Propel/* ?

fsmeier

Heyhey @marco.kaiser ,

does this docs page answer your question? https://docs.spryker.com/docs/cloud/dev/spryker-cloud-commerce-os/troubleshooting/troubleshooting-general-issues/missing-migration-files-on-production-environments.html

So currently the following seems to be the way to go (at least what is intended by Spryker):

1. We normally do not work with migrations during project development (they’re generated from scratch each time on project install)
2. when project goes live, migrations has to be enabled and pushed to repo

Is the linked docs-page helpful? If not, what would have helped you better in that case?

All the best,
Florian

fsmeier

Heyhey @marco.kaiser ,

does this docs page answer your question? https://docs.spryker.com/docs/cloud/dev/spryker-cloud-commerce-os/troubleshooting/troubleshooting-general-issues/missing-migration-files-on-production-environments.html

So currently the following seems to be the way to go (at least what is intended by Spryker):

1. We normally do not work with migrations during project development (they’re generated from scratch each time on project install)
2. when project goes live, migrations has to be enabled and pushed to repo

Is the linked docs-page helpful? If not, what would have helped you better in that case?

All the best,
Florian

marco.kaiser

Perfect, thats fits. :)

marco.kaiser

I have an additional question to the migration files, how to handle tasks like removing customers, permissions or any kind of data from the database. How should we handle such requests?

profuel

Hi, @marco.kaiser !

From my experience, live projects are using some sort of data ans structure migrations.

OOTB Spryker provides Propel migrations as a tool to make this work.

My recommendation:

1. make sure on production you do not run propel:install, rather only migrate and model:build.
2. make sure to create an initial migration to create full DB.
3. upon every DB change, you have to create a migration and commit it.
   1. there's no need to merge multiple migrations from different commits, though keeping migrations in one file for a single commit/feature makes code-review easier.
4. when some data migration or raw import is required, then you create another manual Propel migration.
   1. Also I would recommend creating separate data and structure migrations, including a comment and a link to a ticket into data migrations.

Warning! you have to carefully check each released code to assure that only correct Propel migrations are committed.

s.kroll

But in contrast to the documentation you mentioned @fsmeier, the code in the suite (production install recipe) exactly does this "migration:delete". We for example have projects where we do not commit the migrations at all and do every deployment with "delete existing migrations, generate diff, apply diff" and it works well so far.

sebastian.wagner

@s.kroll so your table propel_migrations now contains timestamps where no php migration files exist for?

s.kroll

@sebastian.wagner exactly.