...
Migrate
Tools
- upgrade status module
- drupal 7 to 8/9 module upgrader
- migrate qa (for QA after content migration. assigns tickets)
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
- no config done in destination, apart from enabling modules
- minimum installation profile
- modules must be enabled in both source and destination
- Limitations
- no views
- no php module
- filter format not recognized
Infrastructure
tracking, tracing, alerts
Possible Grafana for solr tracking or Datadog for tracing
Things that need to be kicked at launch
- Solr
- Memcache
- Circle
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.
...