Publish an Experience to Production
What You’ll Learn
In this section, you will learn:
- A quick refresher on commits and builds
- How to publish an experience to Production
- Updating the Production Search Configuration label
Commits and Builds Refresher
This step will always be done exclusively by the Admin.
Remember from the Overview of Answers Frontend module that when you commit frontend changes, you are presented with a modal to add a commit message and commit tag to the commit.
For the Commit Message, this is to tell yourself and other users what the commit was for and is a standard practice in development. Keep your commit message succinct but descriptive.
For the Tag, this is so that you can easily publish these specific changes. Your tag needs to follow Git conventions so something like “2020-05-02” is valid, but “starting point” is not. You can always go back to a commit and add the tag later. We recommend using something like a date system or a semantic versioning system to keep track of your commit tags.
When you publish a site to production, you will always reference a specific commit tag and never a branch (like “build” or “master”).
Publishing to Production
Once you’ve fully tested the experience in Staging, you can publish to Production from the Sites tab.
Note: Ensure you’ve updated the Configuration Label for your backend configuration in the Experiences tab to the most recent version (i.e. the version you tested in Staging).
On this page, you’ll need to navigate to the Production environment by clicking “Edit” to enter the Site and then clicking the “View Environment” button next to Production.
Within the Production environment, click “New Publish” and click the ‘refresh’ icon next to the dropdown - this pulls the latest tags from Github. Update the Git Reference to the commit tag to publish. Remember to pin Production to a specific (and verified) build. Never pin Production to a branch, that is very dangerous!
Once you select what you want to use, click Continue. You will then be redirected to the publish so you can monitor it in real-time.
As with publishing to Staging, if your publish attempt is successful you will see the Generation Details section updated with the publish attempt and “✓ Success” will show in the Status column. If you click back into the Production environment, you will see the successful publish in the Recent Activity section as well as in the Currently Published Version section.
Updating Production Search Configuration Label
Once you’ve published your site to production, you’ll want to make sure that your Search Configuration labels are up-to-date. As you learned in Search Configuration Overview, your Production label should be on the latest, specific Search Configuration version.
Navigate back to Answers > Experiences > Configuration Labels and confirm that Production is pinned to a specific version number. For example, if Staging is on version LATEST (6), Production should be on a specific version # (likely one of the more recent versions such as 5 or 6). This will ensure that the latest backend configuration is pointed to the frontend production URL.
As you update the Search Configuration going forward, you can test your changes at the staging frontend URL. Once you QA and approve of those changes, you can keep versioning up your backend Search Configuration to the latest, stable, Admin-approved version. The same logic applies to the frontend changes that you make, where you’ll test at the staging URL (in addition to live preview) before updating production.