Calling Developers!
We are reenergizing our code contribution process! Learn More

Should we add the migrations to the git repository

marco.kaiser
marco.kaiser Spryker Solution Partner Posts: 13 ✨ - Novice

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/* ?

Best Answer

Answers

  • fsmeier
    fsmeier Senior Software Engineer & Developer Enablement Advocate Sprykee Posts: 1,005 ⚖️ - Guardians (admin)
    Answer ✓

    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
    marco.kaiser Spryker Solution Partner Posts: 13 ✨ - Novice

    Perfect, thats fits. :)

  • marco.kaiser
    marco.kaiser Spryker Solution Partner Posts: 13 ✨ - Novice

    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
    profuel SSA Sprykee Posts: 35 ✨ - Novice

    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
    s.kroll Head of Technology Spryker @ basecom Posts: 117 ✨ - Novice
    edited July 2023

    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
    sebastian.wagner enrolled to Back End Development Basics Spryker Solution Partner Posts: 9 🧑🏻‍🚀 - Cadet
    edited July 2023

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

  • s.kroll
    s.kroll Head of Technology Spryker @ basecom Posts: 117 ✨ - Novice