Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Drupal migration notes

...

Local Development Environment

Docker

The docker profile we're using is basically wodbi out of the box.

Composer

Need a default composer file

Development server

Naming convention

The d8/d9 development sites should use 'test' not dev. All development sites have -test at the end of their namespace and a -test in the 3rd level domain of their url and a -test for their database name

Kubernetes

Database

Solr (optional, depending on the site)


Migrate

Tools


Basic Migrate Notes

  • Create an inventory of modules used in source and destination
    • Use Upgrade Status module to get an idea of which modules will be ready for migration
  • Understand the assumptions made by Migrate API
    • Drupal Core in source and in destination should be on latest version
      • minimum install profile
    • DON'T do any config in destination, apart from enabling module
  • Limitations
    • no views
    • no php module
    • filter format not recognized
  • enable Migrate, Migrate Drupal, and Migrate Drupal UI modules
  • enable modules in source and destination
  • follow wizard on /upgrade
    • you'll need to specify the databases and the files folder
    • files folder should probably be manually moved to the same server
    • there will probably be a few new modules to install and enable, so double check
  • To use the Migrate CLI, stick with drush 10.3 (as of April 2021)
  • Widget Connector
    urlhttps://www.youtube.com/watch?v=nMJBgu-BW8g

Infrastructure

tracking, tracing, alerts

Possible Grafana for solr tracking or Datadog for tracing


Things that need to be kicked at launch

  • Solr
  • Memcache
  • Circle

Git and Github

Circle and automation



Additional Press launch retro notes

https://docs.google.com/document/d/1lfapq0_Ob4WFHbJtJnH0Ihez7WFMG9dD_N5GEJg9jqk/editPossible Grafana for solr tracking or Datadog for tracing


 Press retro

Goals for the using git branch was to retain history. We fell down a bit on that goal as we still did development on the master branch while work was being done on drupal 8 branch. Recommendation: Use two repos in the future. Still looking for a way to store the relevant information (former drupal 6 site with significant php code in the database) use setting of 'don't allow force pushes to master', force admins to follow the rules as well, and so on. 'Force' apparently breaks the build.

Docker Containers: Containers were well segmented. The php-specific containers were especially helpful here. We mostly used the wodbi containers that handed us phpmyadmin, solr, traffic (we didn't use it, but the namespacing was there). Wodbi gave us a really great base to start with so our docker file is very short. We just needed a time zone information. Made everything super readable and super easy to add to. Also liked the 'init' folder, a place to put scripts that would run everytime the server started up – we could even give them a numbered ordering. Comes from php-fpm container that wodbi bases themselves on. Containers still seem the way that all development is going to go and it's worth the growing pains to learn how to use properly. Containers also run best with k8s.  Recommendation: Stick with containers. Stick with wodby but check for security updates periodically, maybe once a quarter. (update .env PHP_TAG to 7.3-dev, or whichever php we're on, so we pull in changes. in circle, we'll be on a different 'image version' on production, but that will be ok because we're constantly checking.) Maybe move NGINX outside of the container. To update php, we'll use the circleci yml file.

...