Aspenware Release and Update Processes and Timelines

Weeks 1-4

• Research and business analysis

• Development of new features

• Internal testing of new features

• Code completed for release

• Functional testing completed

• Release branch is created and deployed to Aspenware test environments

• Integration testing completed

• Beta release is created and ready to be scheduled for beta test sites

• Release notes and release guides are drafted

• Communication about beta testing availability is sent to customers

Week 5-6

(Beta Test)

• Participating resorts conduct beta testing and provide feedback on any issue that arise

• Any issues that arise from beta testing are prioritized and/or remediated*

• Release notes and guides are finalized

• Production release is created and ready to be scheduled for site deployment

• Communication about release availability is sent to customers and they schedule a deployment

Week 7

• Release is deployed at resort sites that have scheduled it

• Release is in production in customer environments

Role

Name

Email

Work Phone

Cell Phone

(only for emergencies)

Primary Contact

Secondary Contact

Accounting Contact (access to payment gateway)

IT Contact

Notice of new release along with release notes and configuration guides for production-impacting changes are sent out giving resorts the opportunity to take the version.

Resort use the Aspenware Ticket Portal to request the upgrade. See Login - Aspenware Customer Hub

Aspenware deploys the version to the resort test site, smoke tests it internally, and then sends the smoke test checklist to be completed by the resort.

Resort completes the smoke test checklist and feels comfortable with the release, and then contact their Aspenware Representative, thereby signing off on the release. Production upgrades need five business days notice from signoff of the test environment.

Aspenware works with resort to schedule the release.

Resort representatives will select an available release date provided by Aspenware. Resort representatives will provide a list of contacts that need to be included with the upgrade. Aspenware requires inclusion of a resort contact that can review test transactions in the payment gateway portal and the resort POS (RTP or Siriusware).

During this scheduled time, all invited resort representatives, especially the primary contact and accounting representative, are available to answer emails and complete checks requested of them quickly. If they are not available, it is their responsibility to notify Aspenware of their absence so a new time can be scheduled, or a backup can be found.

If the release requires configuration updates in Aspenware Commerce or Unity between the time of the release of the code and the re-enablement of the site, Aspenware will work with the representatives (defined above) to train the contacts on the required configuration and to compile a complete go-live configuration checklist to be completed by Aspenware, and/or some tasks by the resort main contact during the downtime. These configurations will be done from the staging environment by Aspenware and/or the representatives (defined above).

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.

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.

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.

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.

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.

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.

• If any of these checks are not able to be completed in a timely manner, especially the accounting check task above and the primary contact is not able to be reached, Aspenware will follow up with the secondary contact (defined above) to have them follow up with required parties.

• If the uncompleted check can still not be verified after reasonable efforts have been made to reach out, the primary or secondary contact (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 representative (defined above) gives explicit instructions to turn the site back on despite checks not being completed.

• 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.

Once all tasks are completed, Aspenware will email the group of representatives (defined above) declaring that the site is Certified by Aspenware and complete.

1. Create a new account and family member and confirm that it loads in the resort’s production POS with expected information (email, alternate id, name, dob, authentication profile)

2. Checkout with an order using a real credit card

3. Confirm that the order is in production POS under the correct person and for the correct dollar amount

4. Email Accounting contact (defined above) to confirm that transaction is in the payment provider for the correct amount.

   1. Aspenware will email the Order ID, order total, name of ordering product, name of cardholder, last 4 of cc, and expiration date.

   2. The accounting representative (defined above), or someone with access to the payment provider at the resort is responsible for quickly checking the transaction and emailing Aspenware to confirm or deny that the transaction made it in. The accounting representative is also responsible for refunding these test production transactions in the payment provider and/or the POS.

   3. If the transaction is successful, the contact should immediately refund the transaction in the POS.

5. Logout and log back in with an existing credential

6. Confirm that the email is successfully delivered

7. Check store settings in admin to confirm that the correct URL is added and the ‘/’ is present after the URL.

8. Confirm that site is SSL.

9. Click through products and categories on the store to confirm that everything appears to render correctly.

Aspenware will reach out to the resort to get permission before beginning release activities to fix a P1 issue.

The resort will grant permission before Aspenware begins.

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.

1. 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 some reason, the deployment is aborted and the backup DB needs to be restored.

2. If the backup takes longer than expected, or if another factor is delaying the deployment, Aspenware will email the group of representatives (defined above) to re-assess and plan a later or different time.

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.

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.

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.

The checks outlined in the Go-Live Certification Checklist (see above) checks are completed.

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.

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.

• If any of these checks are not able to be completed in a timely manner, especially the accounting check task above and the primary contact is not able to be reached, Aspenware will follow up with the secondary contact (defined above) to have them follow up with required parties.

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.

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.

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.