HomeGuides
Submit Documentation FeedbackJoin Developer CommunityLog In

Deploying blueprints built for Spire

This topic describes how to deploy blueprints built for Spire.

The process for deploying Blueprints in Spire involves pushing changes into the appropriate Git branch. Builds of Blueprint code and Spire code take place at the same time. As Optimizely releases new versions of Optimizely B2B Commerce, the Blueprint is rebuilt using the new version of Spire.

Automated builds are not active until the site is mapped to your Github extensions repository. For Spire sites, your extensions repository must contain a valid Blueprint. When your extensions repository is ready for deployment, you can create a support request with the Spire site name mapped to a Blueprint name.

🚧

Important

Because Optimizely deploys containers with your Blueprint in it, you cannot change the Spire Blueprint on a running site. The Websites drop-down list for Themes will not work for Spire and we will remove this field in the future.

Spire code and widgets

When your Blueprint is built and deployed, any changes you have made to core Spire code will be ignored. Changing the core Spire code should only be used to assist with troubleshooting problems.

Widgets will be automatically upgraded and new widgets or widget features will become available when you deploy, but will not be turned on by default. This means, for example, if you have not customized Order History and Optimizely adds some new functionality to it, it will be available as you upgrade with no developer intervention. You may need to turn on an option in a widget or drag a new version of a widget onto a page to expose the new functionality, but no code merging is required unless a new widget was created as a copy of any existing widget. We
will not overwrite your custom widgets.

Differences in Classic

In Classic, when a Theme is created, it splits off from our reference theme and stands on its own. Nothing in the front-end is automatically updated. This introduces less risk from release to release, unless you want to incorporate new features we built into the front-end in your site or apply any bug fixes. This takes careful merging of the code for
the front end which, while not extensive, can take developer time.

Like a Spire site, a Classic site must also be mapped to your Github extensions before automated builds are active. For Classic sites, your extensions repository must contain at least a valid Extensions.dll. You may also submit a support request indicating that the extensions repository is ready.


What’s Next
Did this page help you?