Table of Contents |
---|
...
If a release is required to address a P1 issue, Aspenware will create a hotfix release. These hotfix releases are developed, tested, and published within 2 business days whenever feasible. Hotfix releases will increment the release number with .1 after the major release version, e.g., if the prior major release was 2.15, the hotifx hotfix release will be 2.15.1. Where .1 indicates a hotfix release to 2.15.
...
For scheduled releases, the following process will be used for Aspenware to certify that a release is completed. The steps in blue are the responsibility of the resort.
Release Pre-work
Timing: 3 - 7 Days before the scheduled release
...
Step | Aspenware Responsibility | Resort Responsibility |
---|---|---|
If deemed necessary by Aspenware, about 1 hr before the scheduled release, Aspenware will take a backup of the current site’s database. Depending on the size of the shop’s database, this may take between 10 min to 2 hrs. Note: Any orders placed between the time the backup is started and the site is taken down with the maintenance page will not be included in the restored site if for any reason, the deployment is aborted and the backup DB needs to be restored to production. If the backup takes longer than expected, or if another factor is delaying the deployment of code, Aspenware will email the group of representatives (defined above) to re-assess and plan a different time. | X | |
If a release requires downtime the site is taken offline. When the site is taken down, a maintenance page will be displayed for the entirety of the release. Aspenware will email all representatives (defined above) to confirm that the deployment is starting and the site will be taken down. | X | |
When the site is down, the new code will be deployed to a staging slot. Once the code deployment is complete to the staging slot, the developer doing the deployment provides a URL to the staging page to the responsible Aspenware Representative. It is the Aspenware Representative’s responsibility to check the site. | X | |
When the staging URL is ready, the Aspenware Representative will step through the go-live certification checklists (see below). Every step on these checklists must be completed before confirming that the production site can be re-deployed and the maintenance page may be removed. The site will not be turned from maintenance mode to live mode unless every step is completed in the checklists successfully, or unless the representatives (defined above) give explicit instructions to turn the site back on despite checks not being completed. | X | |
The Aspenware representative will then complete the upgrade checklist that is unique to the code being deployed and is made the prior week by the Client Services Manager and Release Manager. | X | |
If any of these checks are not able to be completed in a timely manner, especially the accounting check task above, Aspenware will follow up with the primary contact (defined above) to have them follow up with the required parties.
| X (Joint Responsibility) | X (Joint Responsibility) |
Once all tasks are completed, Aspenware will email the group of representatives (defined above) declaring that the site is Certified by Aspenware and complete. | X |
Go-Live Certification Checklist (Resort responsibility in BLUE) |
---|
|
Unscheduled Release Process
For unscheduled emergency releases, such as P1 site outages, which are not planned in advance, the following process will be followed for Aspenware to certify that a release is completed. The steps in blue are the responsibility of the resort.
Day-of-Release Activities
Step | Aspenware Responsibility | Resort Responsibility |
---|---|---|
Aspenware will reach out to the resort to get permission before beginning release activities to fix a P1 issue. | X | |
The resort will grant permission before Aspenware begins. | X | |
If possible and deemed necessary, Aspenware will take a backup of the current site’s commerce database. Depending on the size of the shop’s database, this may take between 10 min to 2 hrs.
| X | |
If a release requires downtime, once the backup is taken, the site will be taken offline. When the site is taken down, the maintenance page will be displayed for the entirety of the release. Aspenware will email all representatives (defined above) to confirm that the deployment is starting and the site will be taken down. | X | |
When the site is down, the new code will be deployed to a staging slot. Once the code deployment is complete to the staging slot, the developer doing the deployment provides a URL to the staging page to the responsible Aspenware Service Representative. | X | |
When the staging URL is ready, the Aspenware Representative will step through the go-live certification checklist. Every step on this checklist must be completed before confirming that the site can be re-deployed and the maintenance page removed. The site will not be turned from maintenance mode to live mode unless every step is completed in the checklist successfully, or unless the RESORT representative (defined above) gives explicit instructions to turn the site back on despite checks not being completed. | X | |
The checks outlined in the Go-Live Certification Checklist (see above) checks are completed. | X | |
The Aspenware representative will then complete the upgrade checklist that is unique to the code being deployed and is made the prior week by the Client Services Manager and Release Manager. | X | |
If any of these checks are not able to be completed in a timely manner, especially the accounting check task above, Aspenware will follow up with the primary contact (defined above) to have them follow up with the required parties.
| X (Joint responsibility) | X (Joint responsibiity) |
If the uncompleted check can still not be verified after reasonable efforts have been made to reach out, the primary or secondary contacts (defined above) only can give permission to Aspenware to flip the site back on despite certain go-live certification checklist items remaining incomplete. The site will not be turned from maintenance mode to live mode unless every step is completed in the checklist successfully, or unless the resort representative (defined above) gives explicit instructions to turn the site back on despite checks not being completed. | X | |
If the site is flipped back on without key tasks being completed, within 24 hours following the flip back, Aspenware and the primary contact should attempt to re-contact those responsible for outstanding tasks. | X (Joint Responsibility) | X (Joint Responsibility) |
Once all tasks are completed, Aspenware will email the group of RESORT representatives (defined above) declaring that the site is Certified by Aspenware and complete. | X |
...
Beta Testing Expectations for Resort Customers
Read all available release notes or release guides specific to the release.
Actively test all product types currently available on your site before the beta testing window closes.
Promptly report any issues that arise with the following information:
Description of the problem.
Detailed steps to recreate the issue, including specific products, quantities, and product dates to use.
Screenshots of errors presented on screens, or the outcome of the error condition (e.g., point of sale order discrepancies).
Info |
---|
NOTE: The sooner Aspenware receives an issue found in beta, the more likely all issues will be resolved in a timely manner and the release will not be delayed. Aspenware will address as many high-priority reported issues as possible. If a show-stopper issue is reported after beta week, it will not be resolved in the current release. However, it could become a candidate for a hotfix release. |
...