Migration

• In D7, we used the Migrate Drupal to Drupal module, what’s the case for D8?
  • Speak on pattern of using Migrate Drupal as a basis for a migration.
  • Migration plugins and yml configuration declarations are an improvement on an already excellent module - if you are going to handle migrations like you did in 7 - which might be appropriate depending on your use case
  • Appropriate where you are significantly revising the content model, configuration or site composition.
• What are some of the pros and cons of the way Migrate Drupal works in D8?
  • Pros
  • Migration of most Drupal settings: registration emails, site name, debug settings, etc.
  • Migration of most fields (work is ongoing to include contrib into upgrade migrations)
  • Migration of all content types with nodes and revisions
  • Cons
  • By default, fixed ids (not ideal for staged work)
  • Miss an opportunity to take out the trash

Configuration management

• Let’s talk about configuration management. I know from working with you guys that you started out using Features...
  • Tried out a features based approach at first - because it was similar to well established patterns in 7 - but abandoned it for the project
  • Feature branch activity then confex seems to be working out well
  • Configuration import and export has inspired a lot of confidence in getting to known states.
  • The challenge is probably in managing environmental config settings - that’s where Master still might have a place.
  • Using configuration export and import committed to git repo.
  • Challenges of local configuration vs production configuration.
  • Managing code review
  • Automated removal of local configuration
  • Would like to know some other people’s workflows