Disclaimer: This website requires JavaScript to function properly. Some features may not work as expected. Please enable JavaScript in your browser settings for the best experience.

Dev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideLegal TermsGitHubDev CommunityOptimizely AcademySubmit a ticketLog In
Dev Guide

Deployment process

Overview of the deployment process

See the Cloud release schedule for important dates, release type, and cadence information.

Upgrade your Configured Commerce instance before requesting deployment.

Hotfixes

If Optimizely identifies an issue that requires immediate resolution outside the normal release cadence, Optimizely builds a hotfix.

Optimizely only builds hotfixes for the current cloud release. Applying the hotfix will automatically update your environment to the current cloud release, if applicable. See the release notes for a list of hotfixes for the current release. You should follow these articles to receive updates.

📘

Note

The most recent hotfix contains all previous hotfixes.

Applying a hotfix will increase your current month's build number, so expect that the final numbers in the version will not match.

Optimizely tests hotfixes specifically for the identified issue and does not perform full regression testing. You or the partner must test all hotfixes in the Sandbox environment before requesting deployment to Production.

Deployment

The Optimizely Service Desk handles new deployment requests for customers in containers. The deployment process varies based on your Configured Commerce instance's hosting infrastructure version. See Infrastructure overview to learn more.

Optimizely Configured Commerce uses a rolling deploy strategy for its environments. This means that there are always containers available to the load balancer. Even during a deploy, websites should not appear as being unavailable to customers.

📘

Note

The Service Desk schedules deployments based on the current extensions available to them when a deployment ticket is created. Partners should wait until they receive a successful deployment email before submitting a ticket to ensure that the extension version they want is deployed.

Redployment

Optimizely Configured Commerce uses a rolling deploy strategy for its environments. This means that there are containers available to the load balancer at all times. Even during a deployment, websites should be available to customers. Site redeployment is scheduled with the Optimizely Support Service Desk team for the changes to take place. Use the ticket form for redeployment requests.

v2+ infrastructure process

📘

Note

The branch used for each environment is the branch requested while configuring build service v2.

Sandbox and additional developer environments

Non-production environment deployment is automatically performed when you commit to the attached git branch. You will receive an email upon success or failure.

Production

You must use the ticket form for all production deployments.

Scheduling

Deployments can be scheduled with Service Desk in 30 minute intervals based on the scheduling windows listed below. All request approvals depend on available resources and your request will either be approved or you will be presented with other time options if the original time requested is not available. Optimizely recommends 24 hours notice for deployment, but requested times are not guaranteed until the Service Desk has confirmed your time slot.

Extensions-only deployments

Extensions-only deployments are available through the Service Desk request during the hours set in your Service Level Agreement.

Scheduling

  • Standard and enhanced support
    • 24/5
  • Premium support
    • 24/7/365 with a target response time of six hours

Base code + extension deployments

Scheduling

  • Monday - Friday 8:00 am - 5:00 pm CST (Affected by United States holidays)

Cancellation

Respond to your original deployment request Support ticket to cancel the scheduled deployment.

Rolling back deployments

Extensions-only

Currently, Optimizely does not support rolling back extensions after a deployment. Deploying a previous extension version follows these steps:

  1. The Service Desk requests you commit the extension version that you would like to a new version.
  2. You commit the new extensions version, wait for the successful build email, and notify the Service Desk that you are ready for deployment.

    📘

    Note

    There is a delay between the commit and the availability of the build in Mission Control.

  3. Service Desk deploys the newest extension's version to the environment.

Example:

  • The Service Desk deployed version 20.
  • You would like version 18 deployed.
  • You commit version 18 as the new version 21.
  • The Service Desk deploys extensions version 21.

Base Code

You are not currently allowed to roll back base code deployments.