Managing Environments and Data
Created 4 years ago by failcookieThis week I have been looking at how I can use Pyro for ongoing client retainers and I wanted to gather some thoughts on some of the best ways to manage data shared between dev environments.
Our standard environments are usually broken down into:
- Dev environment shared between up to 4 devs
- Staging environment for showing client and gathering initial feedback
- Production
Most of the module work and smaller custom stuff won't be much of an issue. The bigger issues I see fall more towards content and ongoing content creation. If we create a page template, we would have to go through and replicate everything across our dev setups, our staging environment and our production. Some pages aren't that rough to replicate, but some pages do have a lot of content and field types to support it. Especially once we bring in grids and have to replicate each grid.
Has anyone found an efficient solution for handling data like this? One of my thoughts was making use of migrations for at least handling field type data, but I haven't tested this theory out yet.
That's really good to know! With the method you mentioned, I would just use the php artisan install command and let it do it's job?
We used to have (will need to again soon) a fork of Pyro. You can put your migrations in the database/migrations table just like everything else and like @dominique said have an extension if you want already included in your composer.json as well as a custom .env file too so you can just change a couple things (ref/domain) in the .env and run php artisan install --ready and be done 😊
That's awesome! Really appreciate the follow up on that. I'm trying to firm up some processes so we can just jump in and try to shift away from Wordpress/Drupal development. You get comfortable in some of those plugins that make your job easier - but it's definitely scary how reliant you are on unofficial plugins just to make your job somewhat easier.
Ya it'll be comforting to know you can build custom so fast now too. Our "investment" on custom addons for clients is so low it competes with spinning up alternatives in the streams module via GUI. It's a nice but weird problem to have 😛
How we (wirelab) currently tackle this is by making an extension containing all our seeders.
I tried using migrations and seeders, placing them in the database folder like one does for laravel. The problem you'll run into when doing that is the fact that
php artisan installruns the migrations and seeders before installing all addons, resulting in errors during installation if you want to seed any addon.When using the extension technique make sure to have the name start with
zzzor something so thatphp artisan installwill install it as last addon.