5

Our team of 10 developers would like to use Dev, Test, Staging and Production environments for our large site. How can we streamline pushing our changes from one site to another, keeping them as identical as possible?

The difference between this question and How to migrate from test environment to production environment? is that we would like to push changes automatically/regularly so that the environments not very different.

We have been using a Dev and Production environment for the past few years, and each environment has its own SVN code repo. The Features module has been used in a few places, but it does not work with Blocks or Content.

One proposal was to use Drush and use archive-dump and archive-restore to push the changes between the environments, but Production has content provided by visitors and users and pushing to Production would wipe out that content.

Has anybody answered this question before?

Improve this question
3

4 Answers 4

Reset to default
3

I use a custom script to automatically pull production to backup and update servers (an update server is a sanitized clone of production with updates applied via pm-update, standing by and ready for testing). You might get some ideas looking at that. However, I'd say that it would be a bad idea to automatically sync either prod to dev, or dev to prod. Only publish to production after a human has tested and validated the release you'd like to bring live. As for automating prod to dev updates, I'd think that the devs would find that very annoying.

One thing that you could pretty easily do is automate the updates of your staging server. Just pull the database down from production, pull the latest code up from the dev branch of your repository, and run updatedb and your test suite. A human could then validate the results and publish the code to production if it was ready.

Improve this answer
1
  • I appreciate the insight. I'm thinking that automatically pushing from one environment to another will only be a good idea for dev -> test. And yes, it makes sense to push from prod -> stg, and then apply updates to stg and test. Very much appreciate your answer!
    – Johnathan Elmore
    Oct 2, 2013 at 14:34
2

Use Features, Context & Boxes for Blocks functionality, along with Deploy and UUID for content.

Whenever possible, use code, CTools exportables, and update hooks in custom modules.

Improve this answer
2
  • Deploy & UUID appear to be alpha, are they worthy of a Production environment?
    – Johnathan Elmore
    Oct 2, 2013 at 14:29
  • They're just fine. I've used both on many sites.
    – Yuriy Babenko
    Oct 2, 2013 at 16:25
0

I was researching something similar just the other day -- except that it was an automatic way to periodically pull down the most recent code from the remote repo to your local dev environment. IIRC it involved a couple of drush scripts. Give me a minute and I know can find it again.

Improve this answer
1
0

Pantheon (https://www.getpantheon.com/) does a great job to manage this workflow. I used to handle this myself with git + features + scripts, but it was more trouble than it was worth. I started using Pantheon and made my life so much easier. I personally would rather spend my time building websites rather than worrying about workflows, servers, etc. But it only has 3 environments - dev, test and live, so it may not work for you if you have to have 4 environments. They have a free tier so you can give it a whirl.

Improve this answer
3
  • How can this manage content changes from one server to another?
    – Johnathan Elmore
    Oct 9, 2013 at 23:57
  • If you read most recommended Drupal workflows, the strong suggestion is to push code upstream (ie up from dev to test to live) and pull content (ie database and files) downstream (from live to test and dev). Pantheon basically has a user interface for each environment that allows you to mode code / db / files between interfaces with a click of a button or couple buttons.
    – stevenkkim
    Oct 17, 2013 at 17:43
  • Thanks for explaining that. We really do want a way to push database stuff up from dev -> test -> prod, but for now we'll just have to manually do it.
    – Johnathan Elmore
    Oct 18, 2013 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.