Deploy to Staging and Production
Deploying puts your application where other people can use it, in one of two places.
Staging is the copy you and your colleagues use to check the application. Your users never see staging, and staging hibernates on a schedule. An admin of the application resumes it before the next use.
Production is the copy your users use. Production runs all the time, without manual start or monitoring, and it handles more people at once than staging.
Both take the same steps, so you learn the procedure once and change only which deployment receives the code. Deploying takes three stages: check your application, deploy to staging, then send the same code to production. Each deployment stamps a version. C3 Code has no rollback control, but you can ask the agent to bring back earlier code in your workspace and then deploy again.
Check your application before you deploy
Confirm all three of the following before you deploy:
- The application runs correctly in Preview. A workspace with a build error produces a deployment that fails immediately.
- Your deployment quota has room. The My Usage and Cost page shows the count under DEPLOYMENTS.
- Any earlier deployment to the same environment has finished. C3 Code rejects a second deployment to staging or production while the first one is still running. Once it finishes, you can deploy to that environment again.
You can deploy without saving your work to GitHub first. C3 Code packages the files exactly as those files stand in your workspace, including edits you have not saved. Commit before you deploy when you want to know later which change produced a running version. An unsaved edit leaves no record to trace back to.
Deploy to staging
Start the deploy from the workspace header, then confirm which deployment receives the code:
- Select Deploy in the workspace header. The Deploy Application popover opens with Staging already selected.
- Confirm Staging is selected.
- Select Deploy to Staging, or Redeploy to Staging when staging already has a deployment. The button reads Validating while C3 Code checks your application.
- In the Confirm Deployment dialog, select Continue.
When staging already has a deployment, the popover shows that deployment's status and version, and who deployed it and when. Select Launch Application to open the running application, or Manage Deployment to open the deployment's page in a new tab. Launch Application is available only while the deployment is running.
When the validation check finds problems, the Package Issues Detected modal opens first and groups those problems by file. Select Fix with C3 AI Assistant to pass the problems to the agent. Errors block the deploy until the agent or you fix them: Deploy Anyway stays unavailable while the modal lists an error. Warnings do not block the deploy, but they can leave the deployed application in a degraded state, so fix them first when you can. If you understand the risk and still want to deploy with warnings, select I understand the deployed app may start in a degraded state, then select Deploy Anyway to continue to the confirmation.
The Confirm Deployment dialog names the environment you are deploying to. When a deployment already runs in that environment, continuing updates it:
Follow the deployment progress
After you select Continue, the Deploy Application popover tracks six steps in order:
- Packaging application
- Registering artifact
- Provisioning environment
- Waiting for environment
- Deploying application to Staging
- Starting services
Above the steps, a progress bar shows Step N of 6 and an estimate of the time remaining. The first deployment to an environment takes longer, because C3 Code sets up that environment first, and the popover says so.
You can keep working while a deployment runs. Changes you make after selecting Continue stay in your workspace, and your next deploy carries those changes. When you close the popover, a banner at the top of the workspace shows the current step. Select View progress in the banner to reopen the popover.
When the deployment finishes, the popover shows the deployment as Running with its new version, and Launch Application opens the running application. When the deployment goes live with known issues, the popover shows the deployment as Degraded, with a Degraded: N issues label. A warning you deployed past can cause this, for example seed data that fails to load when the application starts. Select the label to open Deployment Error Details, which lists each issue and the file it came from. Fix the issues, then deploy again.
When a step fails, the popover reports that the deployment failed, and the banner reads Deployment to Staging failed or Deployment to Production failed. Select View details to read the error, then deploy again. The banner stays until you dismiss it or reload the page.
Once a deployment exists, that deployment runs independently and keeps using resources whether or not you are working. Stop a deployment, resume a deployment after hibernation, and read activity and errors from the Deployments page rather than from the workspace. See Manage Your Deployments.
Send the same code to production
Production takes the same steps against the other deployment. Check staging first, then deploy again with Production selected:
- Confirm staging runs the version you want your users to have.
- Select Deploy in the workspace header.
- Select Production.
- Select Deploy to Production, or Redeploy to Production when production already has a deployment. Clear any package issues the check reports.
- In the Confirm Deployment dialog, select Continue.
Staging and production deploy the same way. Afterward, production keeps running while the application sits idle, and handles more people at once than staging.
What happens when you deploy again
To send your latest changes, deploy again from your workspace, the same way you deployed the first time. Each application has one staging deployment and one production deployment. Deploying again to the same deployment upgrades the version already running.
Two workspaces deploying to staging still give you one staging. The second deploy replaces the first, so confirm which deployment you selected before continuing.
Deploying again has three consequences:
- Each deployment replaces the running application: staging or production now serves the version you deployed.
- Each deployment stamps a new version: the version is built from the package version and the time, so no deployment overwrites an earlier version.
- Each deployment is recorded: C3 Code records the workspace the code came from and the version produced. The deployment shows the last successful deployment alongside the most recent failed attempt.
The first deploy creates the deployment. Every later deploy upgrades that same deployment.
Roll back to earlier code
C3 Code has no rollback control. To run earlier code again, ask the agent to restore that code in your workspace, then deploy:
- When the application is backed by GitHub, ask the agent to roll back to a previous commit, for example "Roll back to the commit before the login change."
- When the application is not backed by GitHub, describe what to undo, for example "Remove the export button and the CSV endpoint you added today."
After the agent restores the code, check it in Preview, then deploy again. C3 Code stamps a new version, and that version carries the earlier work.
Where to go next
These pages cover keeping a deployment current and diagnosing one that fails: