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