How to migrate BREAD from dev to prod?

[zietbukuel]

So, I'm developing a new app and I have some new tables and new BREAD config that I've created in my dev instance. How can I push these changes to my prod instance without having to manually recreate all this from scratch without unintentionally messing up stuff?

Sorry if my question isn't very clear or if this is already covered, but I couldn't find any documentation anywhere or any tutorial on how to achieve this.

[mdelally]

One solution is to back up the dev database to a .sql file and to import that file into the production database. It's a stinky way to do it, but it works.

Another solution I've seen floated - and I think would make more sense for maintainable code - would be to use a SQLite database and assign those models to write to that driver instead. It's likely not that simple, but Laravel does support many drivers out of the box.

[zietbukuel]

The problem with both solutions is that my prod database usually has more and fresh content, if I dump the DB from dev and import it to prod I lose my content/comments/etc which I don't want. I was hoping that I could use something like Laravel migration but generated by Voyager in some way maybe, some config/code that I could push into GIT and then into my prod server.

[whyayala]

I've just developed a habit of creating seeders or migrations that correspond to any changes to the database and BREAD config in my development. It's tedious, but if tested properly you can reproduce the same results when you move to prod or try to spin up the project in another team member's machine.

[mdelally]

@zietbukuel You're only going to need to export/import the following tables: data_rows, data_types, menus, menu_items, roles, permission_role, and settings. These tables are only associated with your unique Voyager configuration. You wouldn't need to copy the tables containing your content as they are decoupled from the Voyager business logic.

Whyayala's suggestion is also a perfect way to handle this and still have maintainable version control for those various settings. I would actually recommend his solution over either of mine.

[fletch3555]

100% agreed with @mdelally's comment

[ShamarKellman]

For this what i do is use seeds. I create all my BREAD stuff using seeds, and seed them in production.

[jeffochoa]

I submitted a new hook to create a BREAD (migration, model and seeder) using artisan https://larapack.io/hooks/voyager-bread-generator

[nosoka]

@zietbukuel

Was in a similar situation and used the process suggested by @mdelally

Used https://github.com/orangehill/iseed to generate the seed files from database, since manually writing seed files was tedious.

php artisan iseed data_rows,data_types,menus,menu_items,roles,permissions,permission_role,settings

[notisset]

@pasok Thank you for sharing, although I think there might be an issue with that.

In my case data_rows was not being seeded at all, what I found is that since data_rows references data_types, the latter should be seeded first (same goes for permission_groups referenced by permissions):

php artisan iseed data_types,data_rows,menus,menu_items,permission_groups,roles,permissions,permission_role,settings

[psierak]

@zietbukuel You're only going to need to export/import the following tables: data_rows, data_types, menus, menu_items, roles, permission_role, and settings. These tables are only associated with your unique Voyager configuration. You wouldn't need to copy the tables containing your content as they are decoupled from the Voyager business logic.

Whyayala's suggestion is also a perfect way to handle this and still have maintainable version control for those various settings. I would actually recommend his solution over either of mine.

This worked for me except I had to go into the bread after for each table and save/update it again for it to show up in role permissions.

[fletch3555]

@psierak, that's correct. Though you could also add Permission::generateFor('BREADSlug') to a seeder (repeated for each BREAD type, and obviously replacing BREADSlug with the appropriate string)

[fletch3555]

I'm going to close this as suggestions have been provided and auto-generating migrations already has a couple issues tracking that request.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you have further questions please ask in our Slack group.