Testing

Changes made in Strata

Sometimes the code change happens in Strata and thereby making it a bit more difficult to create a feature build/preview. Here's how to go out it. First make sure you're on a feature branch in Playset. From here we are going to update our composer.json file to point to our Strata branch that contains the new code.

So in the require section of the composer.json file we temporarily change which version of Strata to pull in, but instead of providing a version number we give it the name of the branch in Strata with you changes, and prefix it with dev-xxxxx. Example if you branch is named my-new-feature it becomes dev-my-new-feature. We also need to tell the rest of the packages that might depend on a certain version of Strata what this branch should be represented as in terms of a version number. Best to use your current Strata version, so if that is 1.0.0 you write it out as as 1.0.0. So the full string would be dev-my-new-feature as 1.0.0.

It's important to NOT use any kind of version constraint marker such as ^ in front of the version number.

Example

{
    ...
    "require": {
        // ...
        "astrogoat/strata": "dev-my-new-feature as 1.0.0", // [tl! focus]
        // ...
    }

Now with that in place, save the file and run composer update [NAMESPACE]/[PACKAGE]. This will link Strata to the new branch and save the changes to the composer.lock file.

Example

composer update astrogoat/strata -W

You should have two changed file, composer.json and composer.lock, commit and these two files and push them up. This should be all that there's needed for the feature build to be created and a QA link to be posted on the Jira ticket, given that the Playset branch that you just pushed to has has a Jira ticket ID in the name, i.e. feature/play-1/my-new-feature.

Testing production data

Being able to pull down current production data and test against that can be helpful at times to better track down bugs without having to either mess around in the production environment (no-no) or meticulously trying to re-create a page from production on your local machine. For this we can instead pull down the latest production backup and import that.

php artisan backup:restore

What the restore will do for you

• Ask you if you want to back up your current databases.

• Find and download the latest production database file from the remote location.

• Extract the file if compressed.

• Replace your current tenant databases with the production ones.

• Replace any production URLs with you local domain as the base URL.

• Reset any app settings from production. More about this in the Reset settings section.

• Attempt to sync up your Shopify product IDs to match the store defined in the Shopify app settings.

  • Example, the backup has production product IDs in the database, but we want to use the test Shopify store in our local environment, so we can test checkout and other various functionality, and, you know, not mess with production data... So we update the Shopify URL to point to our test store URL, but now the Shopify product IDs (shopify_id) no longer match up. Syncing go through all the products in the database and see if it can find the same product (by looking for the same name) in the Shopify store (test store in our case) and if it finds a match it will simply update the shopify_id to the matched one from the remote Shopify store.

You should now have a near complete copy of production on your local machine.

Resetting settings

Settings from production can be tricky to get right. Sometimes we want the same settings for an app as in production, i.e. Discounts thresholds and settings, there's no harm in keeping those from production, other times we absolutely do not want that, i.e. Zaius or Heap public and private keys, we do absolutely not want to bring those back with us to local as it would completely screw with the data that we sent to those services. So to be on the safe side, by default we disable and reset all app settings when we restore from backup. Which makes it a bit of a hassle to then go in and have to manually update the settings that you do want from production. The process can be automated by creating a settings .env file for each site with the values you want to either keep or overwrite.

Read more about how to reset/sync settings from a .env file.

Any encrypted settings will not be kept even though you have specified the app to keep settings. The reason for this is that the decryption will fail if we leave the encrypted values in the settings as the APP_KEY which is used to decrypt the values is different from the one in production used to encrypt the value.