Schedule and automation How does the copy stay current without you thinking of it?
A schedule refreshes the staging environment by itself, every night for example, so fresh data is there in the morning. A lifetime ends it on the agreed date, and the Flow Builder reports when something goes wrong.
Refresh or rebuild, on the hour.
You set the schedule on the page of the staging environment, in the tab "Schedule". A scheduled run asks nothing, it takes the saved settings.
"Refresh data" copies only the database anew; code, themes and media stay. "Rebuild" builds files and database completely anew. Whatever was changed in the staging environment is gone afterwards, with a refresh everything in its database.
"Daily", "Weekly (every Monday)" or "Monthly (every 1st)".
On the hour, in the time zone of the live shop.
A tick checks every five minutes whether an appointment is due, so the run starts in the first minutes after the hour. Shopware runs the tick as a scheduled task; for that the live shop needs a worker, a console worker or an open administration. All schedules with next and last run are shown by the scheduler.
A staging environment with an expiry date.
With "Limit the lifetime", "Valid until" is required. Once the time is reached, the staging environment locks storefront, administration and API and shows "Staging environment expired".
The data stays, new runs are locked, the schedule pauses and carries on afterwards.
A later date or the switch off and saving free it again, at once in the staging environment too.
Seven days and one day before the expiry and on the expiry itself the plugin raises "Staging environment expires soon" and "Staging environment expired". It ships mail templates and matching flows; the flows start switched off, and you choose the recipients in the Flow Builder. The reminder depends on "Remind before a staging environment expires" in the plugin settings.
Events for mails, commands for scripts.
A run has finished, such as a build, a refresh, a check or a comparison.
A run has failed; the run window says in which step.
Somebody cancelled an open run.
Seven days and one day before the expiry.
On the expiry itself.
dvsn-staging:buildBuilds a staging environment with its saved settings, every step in one call; the argument is the name or id.
dvsn-staging:tickStarts due runs and carries on runs whose window went quiet; the same tick the scheduled task gives otherwise.
dvsn-staging:expireReports expired staging environments and upcoming expiries and removes old protocols and anonymization records.
How many runs may run at the same time is set under "Runs at the same time" (default 3). A run above that waits for a free slot instead of failing.
What shop owners ask about it.
Why did my scheduled run not start?
The tick runs as a scheduled task of the live shop. It needs a worker, a console worker or an open administration, and "Carry runs in the background" has to be on in the plugin settings. If a run of the staging environment was already open at the appointment, the appointment is skipped and not caught up; the scheduler shows "Skipped". An appointment is valid for one hour; if no tick comes within it, it is dropped. While the staging environment is expired, its schedule pauses.
Can a staging environment switch itself off after a project?
Yes. "Limit the lifetime" with a "Valid until" date locks storefront, administration and API once the date is reached. The data stays, new runs are locked and the schedule pauses. A later date frees it again at once.
Can I build from the command line or a deployment script?
Yes. bin/console dvsn-staging:build <name or id> builds a staging environment with its saved settings, every step in one call. "Allow the console commands" in the plugin settings switches the commands on or off.
Do I get an email when a run fails?
Yes, through the Flow Builder. For "Staging: Run failed" and the other events the plugin ships a mail template and a flow; the flow starts switched off, you check the recipients and switch it on.
More about the plugin
-
Setting up
The assistant in seven steps, the preflight and the first build.
-
What gets copied
Which files and tables come along, what stays empty and how rebuilding, refreshing and tearing down work.
-
Anonymization
The rule set, the replacements per column, the preview and the record of every build.
-
Protection and access
Password page, IP addresses without a password, default user, credentials and maintenance mode.
-
Emails and calls
Four ways for emails, three for calls from apps and webhooks, plus scheduled tasks and analytics.
-
Services and plugins
Search, Redis, queue, reverse proxy and plugins: what the copy shares with the live shop.
-
Differences to the live shop
The comparison shows extensions, settings, content, files and database structure, each with its side.
-
Hosting and server
What gets written on the server, Apache, nginx, an address of its own, database privileges and SFTP.
-
Comparison with the standard
What Shopware does itself with system:setup:staging and what the plugin adds.
-
Pricing
What a staging environment costs, monthly or yearly, and what each plan includes.