Posted by Johnny.Love on May 3, 2013 at 3:53pm
Hi fellow Drupalists,
I have a question on best practices for a Development, staging, production servers.
Should OS versions, PHP versions, MySQL versions all match?
Thanks in Advance
JL
Best practices for Dev, Staging, and Production servers
Group organizers
Group categories
More Specifically
- Boston Proper (212)
- Cape Cod (30)
- Central Mass (33)
- Metro North (63)
- Metro South (39)
- Metro West (112)
- North Shore (57)
- South Shore (39)
- Western Mass (40)
- Meta-Boston (59)
Hot content this week
-
2 days 18 hours ago
-
1 week 18 hours ago
Comments
Ideally OS, PHP, and Mysql
Ideally OS, PHP, and Mysql versions would be identical on dev, staging, and production. Ideally it's not just the versions that need to be identical, but the configuration files as well.
In practice it's not always expedient to do so, as sometimes you want a powerful live environment and a cheap dev or staging environment. In my experience, the most important of those three is PHP version and configuration.
It's all about your tolerance for downtime. If you're okay with brief outages when you run an update and find a php, mysql, or OS level bug, then it may make sense to skimp costs on getting perfectly aligned dev,staging , and prod.
Software versions across the dev cycle
I would say that it is very important that the staging and production servers have the same versions of the underlying technologies. The point of having a staging version is that you can stage every aspect of the production set-up before you move any changes to production.
The development server may be different, though. If it is, there may be some information in the differences. For instance, I rarely get any kind of memory related error using MAMP for my dev environment, but when I upload to a LAMP environment that is running on a shared server... I may get errors. Since I know that the module I'm testing works in MAMP, I know to look at memory issues for what might be wrong on the LAMP server. Without that information, I might believe that the fault lies in the module, or in my ability to set it up.
Does that help?
One way to achieve easy
One way to achieve easy consistency is to use a similar environment. At JWA we used to simply roll (or refresh) the needed dev or qa server from the stock AMI (now I think we've moved to chef scripts, but same principle), so it takes seconds to provide yourself (or an outside vendor) with a clone of your working environment on an affordably-sized instance (relatively speaking--this is still more expensive than working on a bottom-tier traditional ISP).
This likely breaks for any sandboxes on your local machine or laptop, but that still limits the likely differences in environment with reasonable ease (and, given the control you have over the environment on your personal machine in most instances, you can be relatively close in important specifics like memory limits). The important thing is to realize that there are reasonably accessible tools to make it easy for you to take control of your own environment.
I'm now working on my own projects and having fun getting to know those configuration files and trying to figure out how tools such as drush and features can make standardization simpler even within the idiosyncracies of my desktop machine.
Agreed with everyone else,
Agreed with everyone else, good advice there -- I would reiterate that if possible, your staging site should be refreshed first with a copy of your production site's database and files directory. You would then be deploying to a staging site that is a virtual copy of production. Then in both your QA and your deployment steps, you'll be going through the same thing that you will when the time comes to go live with the changes. The fewer surprises, the better, especially if it is a complex site. Do not assume anything. :)