Copy of Aspenware Release and Update Process

Development and Release Schedules Overview

Aspenware offers continual upgrades to its products, including new features to enhance both the guest and resort experience, and to fix defects in the software. These upgrades are made available to resorts for all Aspenware products in releases. Aspenware offers two types of releases, including major, and emergency releases. Details on each type of release are outlined below. The timeline below gives a snapshot of a release schedule for the first four months of 2021.

• Major Releases (typically 7-week duration) The richly-colored bars represent the period of time when major releases were being developed and tested (2.14= teal, 2.16=dark pink, and 2.18=purple, although only a portion of 2.18 is represented below.)

• Upgrade Windows (3 or 4-week windows when the release version is available for production deployment) The navy bars represent the period of time that the major or minor release was production-ready, for example, customers taking code between 1/18 - 2/3 would be able to take 2.12, between 2/4 - 3/7 2.13 was available, and so on.

• Emergency releases are not represented in this schedule. Emergency releases are created only for issues that meet the P1 definition as outlined in the Aspenware Customer Support guidelines.

Major Release Process/Typical Timeline

Aspenware schedules a major release for its Commerce and Unity products 5-6 times per year. These major releases are typically published every 7 weeks. This schedule varies from time to time, subject to resource capacity for both Aspenware and our customers, especially during holiday periods. Generally, major releases are focused on delivering new features and functionality, although a few high-priority bug fixes may also be included in a major release.

Customers have the opportunity to volunteer to participate in a 1-week beta program during week 6 of development for major releases. Guidelines on beta participation and expectations are outlined in Appendix A below.

Major and minor releases will increment the release number after the decimal, so if the prior minor release was 2.15, the next major release will be 2.16. Emergency releases will increment the release number with .1, .2 after the release version, e.g., 2.15.1. See more on emergency releases below.

In some cases, typically when a substantial change is included in a major release, the entire version may increment, e.g., from 3.2 to 4.0. In this case, such a release could have a different duration than the 7 weeks outlined below.

Minor Release Process/Typical Timeline

In addition to a major release every 7 weeks, Aspenware will also publish a minor maintenance release 3 weeks after the start of the major release. These minor releases primarily include urgent high-priority bug fixes which cannot wait for the next major release and high-priority theming/skinning/branding requests which must be delivered before the next major release.

Minor and major releases will increment the release number after the decimal, so if the prior major release was 2.16, the next minor release is 2.17.

Emergency Release Process/Typical Timeline

In the event of a Level 1 emergency (P1), Aspenware will make every effort to resolve the issue within 1 day within commercially reasonable efforts. Often, P1s can be resolved without a release.

If a release is required to address a P1 issue, Aspenware will create an emergency release. These emergency hotfix releases are coded, tested, and published within 2 business days whenever feasible. Emergency releases increment the most recent release version with an extension, e.g., 2.15.1, where .1 indicates an emergency release to 2.15.

Emergency releases are used only for issues that meet the P1 definition as outlined in the https://hub.aspenware.net/main/Aspenware-Service-Explained.1722253405.html.

Overall Installation/Update Process

The installation/upgrade process varies slightly depending on whether you are taking a scheduled or unscheduled release (emergency release). Aspenware adheres to formalized processes whenever upgrading and installing production code.

The following sections outline the processes that will be followed by Aspenware for scheduled and unscheduled production releases. In order to ensure that Aspenware has the ability to reach out to resort contacts in the case of emergencies and for code upgrades, we do ask that each customer provide Aspenware with the following contacts:

These defined contacts are determined as release decision-makers and stakeholders. Permission to turn sites from maintenance mode to live mode following a deployment must be granted by one of these contacts, otherwise, the site will remain under construction until permission has been granted. 

Scheduled Update Process

For scheduled releases, the following process will be followed for Aspenware to certify that a release is completed.

Steps in blue are the responsibility of the customer.

Release Pre-work

Timing: 3 - 7 Days before the scheduled release

1. Aspenware will send out a notice of the new release along with release notes and configuration guides for production-impacting changes. Customers can elect to take the version to their test environment.

2. Upon electing to take the release to your test environment, Aspenware will deploy the version to your test site, smoke test it internally, and then send the smoke test checklist to be completed by the resort.

3. When the resort has completed the checklist and feels comfortable with the release, they will contact their Aspenware Representative, signing off on the release.

4. Once accepted, Aspenware will work with the resort to schedule the release. They will select an available release date using Calendly, which will send a calendar invite for the time of the release. To invite additional customer representatives (defined above), they will need to include their emails in your Calendly request.

   1. It is expected during this scheduled time that all invited 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.

5. 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 customer 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 customer representatives (defined above).

Day-of Release Activities

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

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

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

2. If a release requires downtime, once the backup is taken, the site is will be taken offline. When the site is taken down, a maintenance page will be displayed for the entirety of the release. Aspenware will email all customer representatives (defined above) to confirm that the deployment is starting and the site will be taken down.

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

4. When the staging URL is ready, the Aspenware Representative will step through the go-live certification checklists. 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 customer representatives (defined above) give explicit instructions to turn the site back on despite checks not being completed.

5. The following checks are required and a part of this go-live certification checklist.

   1. Create a new customer and family memeber 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 inthe customer’s payment provider for the correct amount.

      1. Aspenware will email the Order ID, order total, name of customer 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 customer is also responsible for refunding these test production transactions in the payment provider and/or the POS.

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

   5. Logout and log back in with an existing customer

   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.

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

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

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

8. 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 customer representative (defined above) gives explicit instructions to turn the site back on despite checks not being completed.

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

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

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.

Steps in blue are the responsibility of the customer.

Day-of Release Activities

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

2. The customer will grant permission before Aspenware begins.

3. 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 customer representatives (defined above) to re-assess and plan a later or different time.

4. If a release requires downtime, once the backup is taken, the site will taken offline. When the site is taken down, the maintenance page will be displayed for the entirety of the release. Aspenware will email all customer representatives (defined above) to confirm that the deployment is starting and the site will be taken down.

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

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

7. The following checks are required and a part of this go-live certification checklist.

   1. Create a new customer and confirm that it loads in production RTP with expected information (email, alternate id, name, dob, authentication profile)

   2. Checkout with an order using a real Credit Card - Payeezy and Square payments cannot be completed from a stage URL, so this step can only be done from the production store for those payment providers.

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

   4. Email Accounting contact to confirm that transaction is inthe customer’s payment provider for the correct $ amount.

      1. Aspenware will email Order ID, order total, name of customer 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(s) and emailing Aspenware to confirm or deny that the transaction made it in.

      3. If the transaction is successful, they should immediately refund the transaction in the POS and/or payment gateway.

   5. Logout and log back in with an existing customer

   6. Confirm that email is successfully delivered

   7. Check store settings in Nopcommerce 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.

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

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

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

10. 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 customer representative (defined above) gives explicit instructions to turn the site back on despite checks not being completed.

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

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

Appendix A: Major Release Beta Participation

Beta testing is the option to take unfinalized code* into your test environment to further test and report issues for this unreleased version. During this beta testing window, we have the potential to resolve any issues through code changes prior to creating our final release candidate.

The beta testing period usually falls during week 6 of a 7-week major release development and testing cycle. Your Aspenware Representative will contact you to gauge your interest prior to the beta week.

*Unfinalized code has been tested by Aspenware, but is not the final release version. High priority bug fixes will be committed to the release in week 6 and week 7.

Beta Testing Expectations:

1. Read all available release notes specific to the release.

2. Actively test all product types currently available on your site before the beta testing window closes.

3. Promptly report any issues that arise with the following information:

   1. Description of the problem.

   2. Detailed steps to recreate the issue, including specific products, quantities, and product dates to use.

   3. Screenshots of errors presented on screens, or the outcome of the error condition (e.g., point of sale order discrepancies).

4. Aspenware will address as many high-priority reported issues as possible. Issues identified during beta testing must be reported promptly to Aspenware during beta week (not after). If a show-stopping issue is reported after beta week, it cannot be guaranteed to be fixed in the current release cycle.