This chapter provides detailed deployment steps to help you smoothly publish your project on the Pages platform. Whether you are a beginner or an experienced developer, this guide covers all aspects from environment configuration to actual deployment. By following these guidelines, you will be able to effectively manage project deployment, ensuring its stability and availability in the production environment.
Note:
For any new deployment, Pages will automatically create a new and unique URL, which you can use to preview the latest changes in the project.
Deployment Lifecycle
The deployment lifecycle includes several stages from development to production:
Local Development: You can write code according to your own development habits. It is recommended to pull the latest env file before each development to ensure the use of the latest environment variables.
Submit and Push: After completing the development task, you can push the code to the development branch of the connected Git Repository. Each push will automatically trigger a deployment.
Preview: After a successful deployment, Pages will assign a corresponding domain name to the deployment. You can generate an access link valid for three hours through the "preview" button.
Production: After completing the development cycle, you will eventually merge or submit the changes to the production branch (usually main). Pages will perform the build and deployment process again. After completion, your deployment will automatically be assigned a deployment domain, including any custom domains you have added.
Expired: When there are more than ten successful deployment records, Pages will retain the build artifacts of the first ten deployments in chronological order and mark other successful deployment records as expired. At the same time, expired deployments will return a 401 Status Code. You can use the "Redeployment" feature to create a new deployment with the configuration of that deployment, thereby restoring access to the expired deployment.
Trigger Deployment
Git Auto-Trigger Deployment
After associating the Pages item with the Git repository, the system will automatically listen for push events and trigger deployment. Currently, only submits to the main branch will automatically trigger deployment.
Manual Trigger Deployment
In the Pages Console, you can manually trigger a deployment in the following ways:
Click the "Redeploy" button in the Project List to rebuild the latest deployment configuration.
Select a specific deployment record in the Build Deployment Record to redeploy.
Preview Deployment
For each deployment record, Pages provides a unique Access Link, allowing you to quickly verify the results.
Note:
We strongly recommend adding a custom domain to ensure that your project has a more professional and credible long-term access. For detailed information on how to add a custom domain, please refer to the Domain Management section.
Build logs
The Build Log records detailed information during each build process, including conventional build outputs, success messages, warnings, and special information on failures. These logs are designed to help users quickly locate and resolve issues. By analyzing the build log, you can easily identify potential errors and warnings in the build process, thereby optimizing project settings and improving build efficiency.
Build Materials
The Build Artifacts list all the files generated by the build. You can view the name and size of each file in this list, and also click on specific files to see their Detailed Content, helping you better understand and manage the build artifacts.
Note:
To improve storage capacity utilization, when the number of successful deployment records exceeds ten, the system will automatically Cleanup the Build Artifacts corresponding to the Earliest Deployment Record. You can use the "Redeploy" feature to create a new deployment with the same configuration, thus restoring access to the invalid deployment.
