Testing releases before your customers do
This page is for partners who maintain customer sites. Testing a release on your customers' setups before you deploy it is the best way to avoid surprises, and testing it before it is released helps everyone.
Know what is coming
- Releases are tags of https://github.com/se7enxweb/exponential; watch its releases on GitHub.
- The changes are in the changelog of each version (
doc/changelogs/6.0/) and the release overview (doc/eng-us/release-overview). - Development happens on
main; "Security fixes are made on themainbranch ... and published with the next 6.0.x release" (SECURITY.md). - "A published tag is never changed" (SECURITY.md): a fix arrives as the next release.
A staging copy per customer
- Same PHP version, database, engine and extensions as production.
- Content: a copy without personal data where possible, or anonymized (Protecting customer data).
- Installed from Git, so you can move between versions quickly (Develop with Git).
Test checklist
- To do: Upgrade steps of the release applied (
doc/eng-us/install/11-upgrading.md) - To do: Front page, a content page, search and forms work
- To do: Sign-in to the administration; edit and publish a draft; upload an image
- To do: Each language and siteaccess
- To do: Custom extensions and templates: no errors in the logs
- To do: Cronjobs run
- To do: Caches cleared; performance comparable
- To do: The customer's critical journeys (checkout, membership, ...)
Test early: development versions
Testing main before a release finds problems while they are cheap to fix. Use a staging copy, never production.
Report what you find as issues (Filing bugs well).
Feed back
- Report regressions with exact versions.
- Tell the project when an upgrade went well for a type of site; such reports help others plan.
Related pages
- Keeping customer sites current
- Release and upgrade planning
- Filing bugs well
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.