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

Memecache
- bump up memory to at least twice default
nginx
php
- version should be as high as possible
- version is updated with circle ci and symphony
varnish
- DC NA 2021 - K8s Varnish Cluster Drupal.pptx
- needs drupal modules Purge and Varnish Purge

Database

Solr (optional, depending on the site)

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
  - 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)
- add the credentials with settings.php
- command docs https://www.drush.org/latest/commands/migrate_fields-source/
- this will spit out a bunch of yml files to tailor for custom imports

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/edit

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.

CircleCI: There's one line of setup that goes into the project – into kube config. but aside from that we're only using a config.yml file. defined how to build and push, and defined how to deploy. Will need to be re-written when we go live (pushes to press-test and drupal8 branch). There are fancier ways to go about the file (multiple branches depending on which branch updates and so on) Recommendations: stick with circle, ~~maybe add a line to catch when a build fails and alert us~~. Add behat tests in circle to catch when a build fails. In the future we may want the ability to push specific branches to staging, but not a current requirement. (maybe master never deploys to production?)

Kubernettes: Overall seems to be super successful with our setup. Ryan has been very good at identifying what we containers need to be on k8s and so on. Recommendations: Ryan may want to move NGINX out of docker and into k8s (future enhancement). May need to set up more alerts for K8s for Ryan. This is part of the evolving conversation for circle vs k8s and server team vs devs (don't debundle drupal and php)

Composer file: updating composer itself is set at the docker level, but otherwise composer is working smoothly.

Solr:

Tailwind: Worked exceptionally well. Great find for our projects. Rumor is that 'Tree-shaking' is improved in tailwind 2.0 and it includes a whitelist so we can easily retain any code we only used for views.

Browser not supported