The Setup:
I’m setting up a Wordpress-powered application using Elastic Beanstalk from Amazon Web Services. All development is being done locally under a MAMP apache2/php5 server environment with a GIT repository controlling the entire application root.
Deployment Workflow:
After committing any code changes (edits, new plugins, etc) to the repo the application is deployed using AWS EB CLI’s eb deploy command which pushes the latest version out to any running EC2 instances managed by Elastic Beanstalk.
My Issue:
Sometimes the code changes aren’t exactly syncing up between my development/production environments and I’m not sure how to overcome it. Especially when trying to install and setup plugins like W3 Total Cache or WP Super Cache.
Since my local environment doesn’t have things like a memcahced server installed, but my production environment does (ElastiCache) I’m unable to save the proper settings file and deploy it for use in my production environment. These plugins won’t allow me to select the needed services because it sees them as not available…
It seems I can only get W3 Total Cache to work if I install it directly onto a live production environment, which seems like a bad idea.
Given the above:
-
Am I going about deployments the wrong way?
-
Should plugins like W3 Total Cache be installed and configured on
local development environments and pushed to production environments?
3 Answers
Couple different things going on here, but my two cents:
1) Philosophically: if a file may be modified somehow in any of its remote deployment contexts, don’t keep it in the repo. Since W3TC keeps its settings in a flat file (and that flat file is updated every time you go into the W3TC settings screen in any context and hit “save”), it’s difficult to ensure that changes made in any context make their way back to the repo (and subsequently to your other contexts). So, any config updates made directly on prod will be blown away the next time you push code up. Know what I mean?
2) Since some of W3TC’s functionality is environment specific (as you said, memcahce vs not, apache vs nginx, etc.), it’s not instructive to test it on a local environment that is substantially different than production. You can’t create identical configs, because your environments are not identical. This is logical. I’d consider setting up a staging environment (identical to your prod setup), where you can test your W3TC settings. Once you’ve got your settings dialed in, you can use W3TC’s export/import feature to move settings between environments. And if you want, you can save that export file (rather than the auto-generated settings file) into your repo for future reference. Kind of a poor-man’s SCM, but works for things like this that don’t need to change often, and can stand some manual setup.
There are plenty more “complete” solutions if you want to get into more complex deployment scenarios. If you’re using a tool like Bamboo, you can literally script every aspect of the deploy. But with your setup, I’d just take the W3TC config out of SCM altogether, and take a manual approach. As a long-term goal, maybe look at running virtual machines locally instead of MAMP–they let you literally replicate your prod environment locally. But they come with a steep learning curve.
