Managing Environments and Data
Created 5 years ago by failcookie

This 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.

dominique  —  5 years ago

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 install runs 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 zzz or something so that php artisan install will install it as last addon.

failcookie  —  5 years ago

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?

ryanthompson  —  5 years ago

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 😊

failcookie  —  5 years ago

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.

ryanthompson  —  5 years ago

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 😛