After a successful migration of your code, files, and data to Staging or Production, use the environment URLs to test your site(s) and store(s). For a list of your URLs, see Starter and Pro access information.
The following information provides information on verifying logs, testing Fastly configurations, user acceptance testing (UAT), and more.
If you encounter errors on deployment or other issues when testing, check the log files. Log files are located under the
The deployment log is located in
/var/log/platform/<prodject ID>/deploy.log. The value of
<project ID> depends on the project ID and whether the environment is Staging or Production. For example, with a project ID of
yw1unoukjcawe, the Staging user is
yw1unoukjcawe_stg and the Production user is
When accessing logs in Production or Staging environments, you can use SSH to log in to each of the three nodes to locate the logs. Or, you can use the New Relic Logs service to view and query aggregated log data from all nodes. See View logs.
See the Error message reference for ece-tools to review errors that can occur during the build, deploy, and post-deploy stages.
Check the code base
master code base correctly deployed to Staging and Production environments. The environments should have identical code bases.
Verify configuration settings
Check the configuration settings through the Admin panel including the Base URL, Base Admin URL, multi-site settings, and more. If you need to make any additional changes, complete edits in your local Git branch and push to the
master branch in Integration, Staging, and Production.
Check Fastly caching
Configuring Fastly requires careful attention to detail–using the correct Fastly Service ID and Fastly API token credentials, uploading the Fastly VCL code, updating the DNS configuration, and applying the SSL/TLS certificates to your environments. After completing these setup tasks, you can verify Fastly caching on Staging and Production environments.
To verify the Fastly service configuration:
Log into the Admin for Staging and Production using the URL with
/admin, or the updated Admin URL.
Navigate to Stores > Settings > Configuration > Advanced > System. Scroll and click Full Page Cache.
Ensure that the Caching application value is set to Fastly CDN .
Test the Fastly credentials.
Click Fastly Configuration.
Verify that the values for the Fastly Service ID and Fastly API token credentials. See Get Fastly credentials.
Click Test credentials.
Make sure that you entered the correct Fastly Service ID and API token in your Staging and Production environments. Fastly credentials are created and mapped per service environment. If you enter Staging credentials in your Production environment, you cannot upload your VCL snippets, caching does not work correctly, and your caching configuration points to the wrong server and stores.
To check Fastly caching behavior:
Check for headers using the
digcommand-line utility to get information about the site configuration.
You can use any URL with the
digcommand. The following examples use Pro URLs:
digtests, see Fastly’s Testing before changing DNS.
cURLto verify the response header information.
curl https://mcstaging.<your-domain>.com -H "host: mcstaging.<your-domain.com>" -k -vo /dev/null -H Fastly-Debug:1
See Check response headers for details about verifying the headers.
After you are live, use
cURLto check your live site.
curl https://<your-domain> -k -vo /dev/null -H Fastly-Debug:1
Complete UAT testing
Complete User Acceptance Testing (UAT) on Staging and Production. The following tests are a quick list of possible tasks and areas to test as a Merchant and Customer. Your list may be longer and include additional tests for custom modules, extensions, and 3rd party integrations. When testing, use desktops, laptops, and mobile devices.
If you encounter issues, save your reproduction steps, error messages, strange screen captures, and links. Use this information to investigate and fix issues in Integration environment code and configurations or environment settings.
|Catalogs & Products||
|Carts & Checkout||
|3rd party integrations||
Load and stress testing
Before launching, we highly recommend performing extensive traffic and performance testing on your Staging and Production environments. You should consider performance testing for your frontend and backend processes.
Before you begin testing, enter a ticket with support advising the environments you are testing, what tools you are using, and the time frame. Update the ticket with results and information to track performance. When you complete testing, add your updated results and note in the ticket testing is complete with a date and time stamp.
We recommend that you review the Performance Toolkit options as part of your pre-launch readiness process.
For best results, we recommend the following tools:
- Application performance test—Test application performance by configuring the
TTFB_TESTED_PAGESenvironment variable to test site response time.
- Siege—Traffic shaping and testing software to push your store to the limit. Hit your site with a configurable number of simulated clients. Siege supports basic authentication, cookies, HTTP, HTTPS and FTP protocols.
- Jmeter—Excellent load testing to help gauge performance for spiked traffic, like for flash sales. Create custom tests to run against your site.
- New Relic (provided)—Helps locate processes and areas of the site causing slow performance with tracked time spent per action like transmitting data, queries, Redis, and so on.
- WebPageTest and Pingdom—Real-time analysis of your site pages load time with different origin locations. Pingdom may require a fee. WebPageTest is a free tool.
You can use the Magento Functional Testing Framework (MFTF) to complete functional testing for Adobe Commerce from the Cloud Docker environment. See Application testing
Set up the Security Scan Tool
We provide a free Security Scan Tool for your sites. To add your sites and run the tool, see Security Scan Tool.