Dev Docs

# Production Deployment

  1. Determine the final domain for the website
    • If the website's DNS is hosted in a provider that does not support CNAME/ALIAS records in the apex or "root" domain (e.g. example.com), which is the case with most DNS providers such as GoDaddy, then the www subdomain must become the final domain (e.g. www.example.com). Check step 10 below for more details
  2. Create a new database in the classic-prod-shared RDS instance (which you can find in the us-west-2 zone)
    • Connect to the RDS instance with your preferred mysql client using the db_master_user to have permissions to run the commands (get the credentials from SSM (opens new window) or ask around).
    • CREATE SCHEMA client_prod;
  3. Create a new MySQL user and grant all privileges to the new database
    • CREATE USER 'client_prod_user'@'%' IDENTIFIED BY 'MyStrongPasswordHere' (use passwordsgenerator (opens new window), checking "Use Letters, Use Mixed Case, Use Numbers" and password length 16)
    • GRANT ALL PRIVILEGES ON `client_prod`.* TO 'client_prod_user'@'%' IDENTIFIED BY 'MyStrongPasswordHere'
  4. Create a customer infrastructure profile in the classic-infra repository on the customers folder, once configured run terraform apply.
    • Before running terraform apply, add a new client_prod_password ssm parameter in SSM (opens new window) using SecureString type and use as a value MyStrongPasswordHere
    • An SSL cert will be generated, for it to be validated the correct DNS entries need to be added to the target production domain. The DNS record changes in this step will only deal with the cert generation and not with the website itself.
    • If you have access to the DNS panel of the domain, apply the ACM Certificate record changes immediately, otherwise, contact the client's IT team to do so ASAP
    • Terraform WILL hang if the certificate is not yet valid, you can safely interrupt it (ctrl+C) until the DNS records for the cert are validated and then run it again
  5. Sync S3 assets from the development bucket into the client's production bucket and ensure they are cacheable
    • aws s3 sync s3://client-stage-uploads-123 s3://client-prod-uploads-123
    • This command is supposed to be run after the first one (it's not the same, but a second step)
      • aws s3 cp s3://client-prod-uploads-123 s3://client-prod-uploads-123 --recursive --expires 2034-01-01T00:00:00Z --acl public-read --cache-control max-age=2592000,public
    • If the Path setting in Offload Media Lite is not s3-uploads/ then the cdn.client.com will not work as expected. You will to instead do:
      • aws s3 sync s3://client-stage-uploads-123/old/prefix s3://client-prod-uploads-123/s3-uploads
      • Ten in the next step, you MUST replace the path and original_path columns in the as3cf_items database table with the new prefix, keep in mind that if the site is multisite then there will be many as3cf_items tables (e.g. wp_1_as3cf_items), all of them need to be replaced.
        • Example: wp search-replace 'wp-content/uploads/' 's3-uploads/' wp_as3cf_items --include-columns=path,original_path --url=https://new_production_domain.com/ --all-tables-with-prefix
      • This can also be done automatically by the paid version of the plugin (see https://deliciousbrains.com/wp-offload-media/doc/how-to-move-media-to-a-new-bucket-path/)
    • Double check all terraform files to ensure that everything looks good
  6. Populate the production database with the staging database (using for e.g. mysqldump), replacing the domain, and the S3 bucket references
    • wp search-replace client-stage.sidewaysdigital.com www.client.com --precise --all-tables
    • wp search-replace client-stage-uploads-123 client-prod-uploads-123
  7. Ensure all pending changes were merged and deployed to the production branch
  8. Test the deployed production branch by spoofing your local DNS records:
    1. Run ping <distribution_id>.cloudfront.net to get a valid server IP. The CloudFront URL comes from the Terraform output in step 2.
    2. Add <ip> www.client.com and <ip> cdn.client.com to your /etc/hosts file
    3. Verify www.client.com is fully functional (images might be missing)
  9. Fix images not being visible by changing the settings of the Offload Media Lite plugin
    • Since v2 of the sw-classic-skeleton, this is configured in code (see ./config/application.php)
    • Path MUST be s3-uploads/
    • Copy Files to Bucket, Object Versioning, Rewrite Media URLs MUST be on
    • Custom Domain (CNAME) MUST be cdn.client.com
    • See https://www.continentalventures.com/wp-admin/options-general.php?page=amazon-s3-and-cloudfront for an example configuration
  10. Release the website to the production domain
    • Point the apex, www and cdn domains to the CloudFront distribution using a CNAME record.
    • If the DNS provider doesn't support apex CNAME records:
      1. SSH into the hoss-prod-apex-to-www-redirects (instance id i-0ed07689f238c4c17) instance and copy an existing Nginx configuration from one of the existing sites, change the config's values to match the domain you are redirecting and remove all SSL-related settings. (ask for the ssh-key)
      2. Point the apex A record to the hoss-prod-apex-to-www-redirects (instance id i-0ed07689f238c4c17) server's ip
      3. On the hoss-prod-apex-to-www-redirects, run certbot to generate a new SSL cert. The SSL cert is needed for https://client.com to correctly redirect to https://www.client.com.
        • cd /etc/nginx/conf.d/ this is the path where you can find existing configs to copy and modify and where you have to run certbot
        • sudo certbot and follow the instructions
      4. Is assumed that you know where the nginx config files are and all the necessary commands are needed to add a new config.
    • If you don't have direct access and need to contact the client's IT team to apply these changes, you should be ready to run the certbot command above as soon as the DNS changes are applied by the client, delaying this will cause accessing the apex domain (client.com) to redirect to some invalid website and/or show SSL errors until certbot runs correctly.
  11. Make sure to remove any testing records in your /etc/hosts file.
  12. Profit

←