From preview to production
Use the resourceA preview environment should help your team make a production decision. This workflow connects a specific code change, realistic application tests, release approval and live verification. Intercube provides the environment, included deployment pipeline and engineering support around that route.
- Author
- Intercube
- Published
- Reading time
- 6 min read
The release route, step by step
Download MarkdownUse each stage as a handover: an owner carries out the work and records the result before the release moves on. Download the editable workflow for your team. On-page ticks stay in this tab.
0 of 13 checks completed
Identify the change
Owner: Developer
Result: a reviewed commit and a clear description of the application or data change.
Build through the pipeline
Owner: Developer + Intercube
Result: a traceable build with inspectable stages and logs.
Test in preview or staging
Owner: Application team
Result: a release candidate checked against representative services, without touching live customer transactions.
Approve the production release
Owner: Named release owner
Result: an accepted candidate, deployment method and recovery decision.
Deploy and verify
Owner: Application team + Intercube
Result: a confirmed production release, not only a successful pipeline run.
01
Make the candidate identifiable
Record which commit was tested and which build will reach production. A green preview is useful evidence only while it describes the candidate you intend to release. If a new build or configuration change produces a different candidate, repeat the relevant checks.
OWASP recommends traceability between source, build and release. Use that principle in the release record: the change, pipeline run, acceptance result and person approving production should belong to the same candidate. It makes both investigation and the next deployment easier.
02
Give preview a concrete testing job
A short-lived feature preview can help a supplier reproduce an issue or let a customer review a change. A longer-lived staging or acceptance environment supports broader release testing. Choose the environment around the work: runtime and service compatibility, data shape, integrations and the people who need access.
Keep testing separate from live transactions. Use suitable test data, test payment credentials and controlled email delivery, and restrict access to the people involved. The Intercube team can prepare the environment and help your developers resolve infrastructure or deployment questions before production is involved.
03
Connect acceptance to managed operations
Our build and deployment pipelines are included in the managed hosting plan. Your team can use Intercube for this release route without maintaining a separate GitHub Actions deployment workflow or paying a separate runner bill for that pipeline. Build stages, run history and logs keep the release inspectable when something fails.
Intercube engineers operate the infrastructure and support the release environment; your team owns application behaviour and acceptance. For compatible releases, zero downtime deployments keep the application serving traffic during the handover. Schedule maintenance when a change needs a coordinated database or application transition, then verify the actual customer journey after deployment.
Keep the release connected
- Identify the reviewed commit and build.
- Give preview a named testing purpose.
- Control test data, access and external effects.
- Approve the candidate and deployment method together.
- Verify production behaviour after the pipeline finishes.