More questions about Dev to Test to Live

anton
New Member

Hi guys,

I received several answers on this in the past, but I wanted to make sure I understand every detail of the workflow and won't break or delete anything by accident.

Background info

I'm doing some changes in the portal, including:

  • Look and feel and content of several blocks
  • Look and feel and content of several views
  • New APIs via the SmartDocs
  • New JS/CSS via Git

I will need to push everything to Test and then to Live.

I was suggested to follow these instructions:

https://pantheon.io/docs/pantheon-workflow/

According to this document, I will need to push only the Code from Dev to Test. Then move DB from Live to Test. Test everything and then push the code from Test to Live.

Question #1

Is this correct - will it move all the changes I mentioned above to Live or will I need to use Features module for something?

Question #2

Also I've noticed that when I edit views and change their contents on Dev portal, the changes appear in all the three environments, including Live. Is this OK?

Question #3

The article on Pantheon mentions 5 options to deploy Configuration as code - hook_update_N, Views export to Code, Features module, Drupal 8 option which is not relevant for me.

Do I need to use one of these or all of them?

Thanks in advance,

Anton.

Solved Solved
1 2 299
1 ACCEPTED SOLUTION

Hey Anton,

Below are a couple of answers to your question about workflow based on my experience with Pantheon.


According to this document, I will need to push only the Code from Dev to Test. Then move DB from Live to Test. Test everything and then push the code from Test to Live.

Question #1

Is this correct - will it move all the changes I mentioned above to Live or will I need to use Features module for something?

Yes, this is a valid workflow in Pantheon. The features module is for committing developer portal configuration settings to code. You'll want to leverage features for keeping key configuration settings in a known state and maintaining revision history in git. Here's a link get started.

Question #2

Also I've noticed that when I edit views and change their contents on Dev portal, the changes appear in all the three environments, including Live. Is this OK?

Generally in Pantheon, content moves down rather than up. The default Pantheon workflow should be moving content down from live to your other environments. So changes directly in live should show up in the other environments. Moving the other direction isn't recommended unless it's intentionally done. It sounds like your site may be leveraging some sort of other deployment mechanism in additional to Pantheon to move content up.

Question #3

The article on Pantheon mentions 5 options to deploy Configuration as code - hook_update_N, Views export to Code, Features module, Drupal 8 option which is not relevant for me.

Do I need to use one of these or all of them?

It's recommended to keep key configuration settings in code as features so that you'll have a known state to refer to. hook_update_N should be leveraged for one time configuration settings that need to be automated by running update.php. Views export to code is a manual way of moving specific view between environments by generating code snippets that can be copied and pasted between them. Under the hood, features will leverage views export to code and package your views code into a module.

View solution in original post

2 REPLIES 2

Hey Anton,

Below are a couple of answers to your question about workflow based on my experience with Pantheon.


According to this document, I will need to push only the Code from Dev to Test. Then move DB from Live to Test. Test everything and then push the code from Test to Live.

Question #1

Is this correct - will it move all the changes I mentioned above to Live or will I need to use Features module for something?

Yes, this is a valid workflow in Pantheon. The features module is for committing developer portal configuration settings to code. You'll want to leverage features for keeping key configuration settings in a known state and maintaining revision history in git. Here's a link get started.

Question #2

Also I've noticed that when I edit views and change their contents on Dev portal, the changes appear in all the three environments, including Live. Is this OK?

Generally in Pantheon, content moves down rather than up. The default Pantheon workflow should be moving content down from live to your other environments. So changes directly in live should show up in the other environments. Moving the other direction isn't recommended unless it's intentionally done. It sounds like your site may be leveraging some sort of other deployment mechanism in additional to Pantheon to move content up.

Question #3

The article on Pantheon mentions 5 options to deploy Configuration as code - hook_update_N, Views export to Code, Features module, Drupal 8 option which is not relevant for me.

Do I need to use one of these or all of them?

It's recommended to keep key configuration settings in code as features so that you'll have a known state to refer to. hook_update_N should be leveraged for one time configuration settings that need to be automated by running update.php. Views export to code is a manual way of moving specific view between environments by generating code snippets that can be copied and pasted between them. Under the hood, features will leverage views export to code and package your views code into a module.

Great Answer @kengilbert , +1