Staging, Production and Milestones
Qik keeps the changes you're working on separate from what your visitors see. You edit a working draft, publish it as a release, and mark the releases that are ready for the public as milestones. Each application then chooses which of these it shows, so a staging site and a production site can run from the same interface.
Key concepts
| Term | What it is |
|---|---|
| Working Draft | The interface as it is in the builder right now. Clicking Save updates the draft. Visitors only see it on an application set to show the working draft. |
| Release (published snapshot) | A frozen copy of the interface, created each time you click Publish in the Release Management panel. Later edits to the draft don't change it. |
| Milestone | A release marked as production ready. You can mark or unmark any release as a milestone at any time. |
| Interface Version | A setting on each application that decides which of the above it serves. |
The Interface Version setting
Open an application from Apps. On the Configuration tab, the User Interface section has an Interface Version setting with four options:
| Option | The application shows… | Typical use |
|---|---|---|
| Current working draft | Every saved edit, as soon as you save. | A private development or preview site. |
| Latest published version | The most recent release, whether or not it's a milestone. | A staging site for reviewing a release before it goes public. |
| Latest production milestone | The most recent release marked as a milestone. | Your live, public site. |
| Specific version | One release you pick in the Interface Snapshot field, and nothing newer. | Freezing a site on a known-good version. |
When you create a new interface, Qik offers to Create a production application and Create a staging application for you. The production application is set to Latest production milestone and the staging application to Latest published version, both on .sandbox.qik.dev addresses. You can change either at any time.
A typical release
- Edit and save. Make your changes in the interface builder and click Save often. Check them in the preview window, or on an application set to Current working draft.
- Publish to staging. Click Publish (top right of the builder). This saves your work and opens Release Management. Enter a Commit Message describing what changed, leave Production Ready unticked, and click Publish. Applications on Latest published version (your staging site) now show this release, while your production site stays as it was.
- Review on staging. Click the staging domain listed under the release to open it.
- Go live. In Release Management, switch on the Milestone toggle for the release, or choose Mark as a milestone from its ⋮ menu. Applications on Latest production milestone now show it.
If you're confident in a change, you can skip the staging step and publish straight to production by ticking Production Ready when you publish. The new release is created as a milestone.
Reading the Release Management timeline
The timeline lists every release, newest first, with its commit message, time and who published it. The Working Draft sits at the top. Under each release, Qik lists the applications currently showing it, with their domain and a note of why:
- Realtime development: the application shows the working draft.
- Set to latest publish: the application follows the newest release.
- Set to latest milestone: the application follows the newest milestone.
- Locked to this snapshot: the application is pinned to this specific release.
Click the pencil next to an application to change its settings without leaving the builder. Older releases load as you scroll, or with Load older releases.
Rolling back
There are three ways to undo a bad release, from quickest to most permanent:
- Unmark the milestone. Switch off Milestone on the problem release. Applications on Latest production milestone fall back to the previous milestone straight away.
- Pin the application. Set the production application's Interface Version to Specific version and choose a known-good release in Interface Snapshot. It stays there until you change the setting again, ignoring any new milestones.
- Restore an old version into the draft. From a release's ⋮ menu, choose Open this version in editor. The builder loads that release as your working draft. Save to keep it, then publish it as a new release (and milestone). Your newer work is replaced in the draft, but the newer releases stay in the timeline.
When will visitors see the change?
Publishing a release, or marking or unmarking a milestone, refreshes every application that uses the interface, so changes normally appear within seconds. Browsers and the network can briefly hold on to the previous version. If you don't see a change, open the site with ?reload=true on the end of the address (the domain links in Release Management already do this), or wait a few minutes. Stylesheet changes may also need a hard refresh in your browser.
Some application settings live on the application rather than in the interface, so they take effect without publishing. These include the favicon, domains, redirects and permissions.
Important things to know
- Publish before you rely on a milestone site. If an application is set to Latest production milestone but the interface has no milestone yet, or Latest published version with nothing published, it shows the working draft instead. The same happens if you unmark every milestone. Always keep at least one milestone once a site is public.
- Specific version must point at a real release. If the pinned release is deleted, or doesn't belong to the application's interface, the site shows an error instead of content. Re-pin it or switch to another option.
- Interface Version can be left blank on older applications. A blank setting behaves like Current working draft.
- Releases are snapshots of the interface only. Content such as articles, events and images is loaded live, so it changes as soon as it's edited, whatever release is showing.
Permissions
- Saving the working draft needs permission to edit the interface.
- Publishing needs permission to create interface snapshots. If Publish fails with a permissions error, ask whoever manages roles in your organisation to add it to your role. See Roles and Permissions.
- Marking or unmarking milestones needs permission to edit interface snapshots.
- Changing which version an application shows needs permission to edit the application.