From MAMP to Vagrant and Back Again

One of the most rewarding things about web development is that it’s always changing. New code specifications, design trends, device capabilities, programming languages, API integrations… Wait, did I say rewarding?

Yes, it can be overwhelming, but for me it is also rewarding. Especially learning new development tools. Like a lot of folks, a few years back I switched my local WordPress development environment from MAMP Pro to Vagrant / VVV. At the time it was the trendy thing to do, and still is I’d presume. Quite a few influential developers were making the switch. My Twitter feed was overflowing with Vagrant awesomeness and tutorials on how to set it up. After (quite a) few initial hiccups, I had a Vagrant environment up and running, with VVV to manage WordPress.

While the initial setup wasn’t as smooth they said it would be, I was very excited to be learning some new tricks, using the command line, and being part of, well, the cool developer crowd. Yes, Vagrant took a long time to launch every morning, and even longer to shut down at night. But hey, it’s the price of progress I thought.

Well, a few months ago I switched back to MAMP Pro. Here’s why.

Matching development and production environments

One of the most compelling arguments for switching to Vagrant is that it allows a developer to set up a virtual environment that matches exactly the final production server configurations. This sounds both reasonable and good. In practice, however, I don’t really need this. And I wasn’t actually using it either.

VVV is a Vagrant configuration specifically designed for WordPress and comes with a default configuration. It also comes with the ability to alter that configuration, but I never took the time to do so. Perhaps I should have, but every WordPress site I’ve built has worked fine no matter what production environment they ended up in. The differences between environments never actually crossed my mind, because it never seemed to actually matter. I still to this day don’t know if a site would run differently on PHP 5.5 vs 5.6. Or what exact version of MySQL. As long as the server is hitting the WordPress minimum requirements, maybe it doesn’t matter.

MAMP doesn’t allow for much configuration either, so perhaps this is a draw. But matching dev environments is the first reason on most Why Vagrant articles, and I just took it away. So, strike 1.

Getting up and running

While most tutorials on how to set up Vagrant / VVV show how clearly easy it is, my experience was anything but… I followed along installing the necessary components and ran my first Vagrant up – and nothing. Tore it all down and tried again – nothing. Tore down and tried a third time –  wha-la – I guess third times are a charm. I’m not sure what went wrong the first couple of tries. Perhaps I’m just an idiot. I’ll admit it was pretty exciting to type that first (successful) Vagrant up in Terminal and see a default WordPress site sitting there. I quickly added Variable VVV and a VVV Dashboard I was off and running with a shiny new development environment.

Too bad it took me heavy parts of multiple days to do so. MAMP is not perfect, and is certainly a PITA to update, but getting it up and running is as easy as 1. Launch the App. 2. Start server. 3. That’s it.

Keeping Vagrant running smoothly

If you talk to a developer who’s used Vagrant long enough, they’ll tell you a time or two they’ve screwed it up somehow. I certainly did that a bit in the beginning, without knowing what or why. Some mornings Vagrant simply wouldn’t load, or I’d get an SSH timeout error. Without knowing exactly what I was doing, I’d try reprovisioning, or halting and restarting, and sometimes re-installing the entire thing. The hours of lost time trying to troubleshoot were astounding, even for someone who loves to waste time troubleshooting. I should have been getting real work done.

I was finally able to get reliable, steady production out of Vagrant after getting a new 5K iMac and installing everything from scratch. There was clearly some configuration or setting on the old computer that was mucking up Vagrant. From then on Vagrant was thankfully very stable. So kudos to nearly two years of Vagrant smoothness. And also kudos to MAMP, because I’ve never screwed it up.

Vagrant performance

For the most part, the speed of Vagrant was okay. Not great but it didn’t suck either. Except for the days that it did. I still don’t know why, but every now and again page load speeds would just drop, making development nearly impossible. If you Google the keywords Vagrant slow you see the first article is titled How to make Vagrant performance not suck. I tried following along but that article is clearly a notch or two above my pay grade. Nothing I did seemed to change the performance on these days and I just ended up dealing with it.

Since Vagrant is a virtual machine, it can only use as much resources as you give it. And perhaps it’s my bad that I didn’t provision more, but what ever the default amount of RAM and CPU was given is what it uses. I may be mistaken, but MAMP might have the entire cadre of resources my machine has at its disposal. I’ll say that I’ve never run into a performance is

vagrant up / vagrant halt

The other speed issue has to do with getting going in the morning, and shutting down at night. I suspect the slow startup and shutdown procedures has to do with the number of sites I had added to the box (20 or so). vagrant halt normally takes 4-5 minutes to run. I shut down every day, and never liked turning off the computer without first shutting down Vagrant. Maybe it doesn’t matter, but on the days I was running out late those 4 minutes seem like forever. MAMP shuts down with ⌘-q

My a-ha moment

I’d still be using my Vagrant development environment today if I hadn’t attended WordCamp SLC this year. Chris Reynolds of WebDev Studios gave a talk titled Building WordPress for Enterprise Clients (or How I Learned to Stop Worrying and Deal With My Imposter Syndrome). Amongst a ton of great information about how he goes about his work, he lightly mentioned how he’d gone back to using MAMP Pro again for development. He summed it up with the following slide:

building-wordpress-for-enterprise-clients-or-how-i-learned-to-stop-worrying-and-deal-with-my-imposter-syndrome-23-638
No on ever complains about blowing up their MAMP install.

I don’t know Greg Rickaby but I could see the wisdom in his words. I went to work the next day and dusted off my old copy of MAMP. Then upgraded to Version 5.

Conclusion

In the end, I’m glad I learned how to use Vagrant. It served me well for over two years. Yes it has it’s issues and took up too much of my time. Yes it’s still cool and yes it’s still fun to run vagrant up. Is MAMP perfect? No. I really (really) wish they’d figure out how to upgrade the app with single click. But it fires up quickly, is reliable, and performs really well.

But maybe I should be looking at Docker.

8 thoughts on “From MAMP to Vagrant and Back Again

  1. This is a great article and it reaffirmed by gut instinct to stick with MAMP Pro.

    However, regarding “No one ever complains about blowing up their MAMP install,” I recently needed MySQL 5.7 and in trying to update MAMP I horribly, horribly broke it and killed several databases. I won’t be trying that again; MAMP is great if you can work within the limits of MAMP.

    1. Well, shortly after writing this article I again moved on from MAMP… I’ve been using Local by Flywheel for what looks like almost a year now. Haven’t really looked back.

      Should probably write up another post about that…

      1. I’m still on MAMP locally, but increasingly unhappy with it. I had a huge issue where my local uses MySQL and my production site uses MariaDB and I found a query that produces totally different results between the two systems.

        And my new WordPress workflow (Sage 9) requires yarn, composer, and webpack, which makes it a bit more challenging to deploy.

        We’ve settled on CircleCI for the deployment path, and CircleCI uses Docker images.

        This has me curious about Docker solutions for my local Mac environment… which circles me back around to wanting to try Flywheel for my next project.

        1. It sounds like you’re way more versed in setting up dev environments than I. I like Local because I don’t have to think about it. As fun as it was learning Vagrant, I’m just happy to get work done. Good luck!

          1. Ha! No, I had to pay a guy to set up CircleCi for me. =)

            But when I saw what he did — well, it’s essentially a Docker script file with instructions on how to instantiate a linux server with apache, mysql, php, composer, and some other utility apps. And then additional lines of text execute a pull from our github repo, runs composer update and yarn run build:production, and pushed the resulting theme to our live server.

            It’s about 30 lines of code all told and takes about 5 minutes to complete.

            And because it’s basically docker… that same script file with minor mods could be used to install a working copy of my whole project on any local or remote server.

            In theory, anyway. =)

Leave a Reply

Your email address will not be published. Required fields are marked *

Ready for a refreshing experience on your next website design?