this year will mark our sixth year using Trellis and it literally changed our lives (and agency) and helped us improve our customer retention so that at the moment I have 18 VMs (one of them holding 16 sites).
As you can imagine (and other users actually pointed out) they take a lot of space on my MacBook.
Sadly destroying and rebuilding VMs on demand is not feasible, I was on the Docker lookout but when it comes to provision and configure remote servers Trellis still takes the cake.
I get and understand that Dev/Prod Parity is a must have but is it so much of a bad idea to:
Start the project as a “normal” Trellis/Bedrock/Sage enviroment to test everything up
After an initial setup and testing of Trellis-managed features (such as hooks and Nginx redirects) destroy the VM
Switch to a Local Development alternative such as Valet / Lando / Local finding a way to route them to the site folder in the Trellis project and manage database and uploads synchronization – this way I could keep working on the Bedrock / Sage folders using Trellis for deployment while having another platform to develop locally.
In case of additional changes to the Trellis-managed features move everything over to the VM, test everything and deploy + provision the remote servers
I’m looking to try this out on a smaller project we’re about to start: the cons I’m encountering in this is the missing dev/prod parity and the overall complexity of setting up custom routings / switching over the data but managing the VMs toll on my hard drive has become almost a weekly issue.
Years ago I setup things this way at an agency with lots of clients where devs were struggling with all the different VM’s and the time for local provisioning. The differences in dev/prod parity can bite you in the ass, but for most sites in an agency environment it’s probably fine.
Although moving DB dumps around may be a bit time consuming that could be solved through some automation rebuilding the VMs would longer times and if that happens too often it’s an issue.
Thank you @ben . That driver setup looks really interesting, I’ll test it right away this evening.
By the way since we have some clients that require almost a day-by-day care / development I could keep those on their VMs and switch the smaller / less recurrent ones on a Valet setting.
An alternative was to move all them to a single VM but I’m not too fond of that either.
I’d like to thank @ben for pointing out @danielroe 's driver for Valet: we’ve implemented it on some of our sites and it’s actually a lot faster than using VMs.
Of course we have to double check everything on the VM especially after updating to the latest version of Trellis but otherwise everything works great.
Lots of folks on here that are using Trellis but not using it for local development, or at least not 100% of the time
