Deployments log in the VIP Dashboard

The Deployments panel provides a log of deployments made to a WordPress or Node.js environment and the ability to roll back an environment to a previous deployment. Deployments are logged for both the Default Deployment method and the Custom Deployment method. The Deployments panel is located in the application view of the VIP Dashboard.

Deployments listed in the Deployments panel are environment-specific (e.g., production, develop). A different environment can be selected from the dropdown located at the upper left of the VIP Dashboard application view.

Deployments from the past three months are listed in the main view, beginning with the most recent. Information related to each deployment is displayed across four columns.

• Commit: The GitHub SHA hash for a deployment that is linked to a more detailed view of that single deployment.
  • An “Active Code” label indicates that the listed deployment is currently running on an environment.
  • A “Custom Deploy” label indicates that the listed deployment was made with the Custom Deployment method.
• Description: The deployment’s commit message.
• Status: The deployment’s status, which may include a progress indicator for builds not yet complete, and the time required to build the application’s code for that deploy.
• User: The GitHub username for the user that made the commit.
• Started: The timestamp in UTC when updates pushed to an environment’s repository were detected.
• Action: Previous deployments that display a button in this column are eligible for a rollback.

Access

1. Navigate to the VIP Dashboard for an application.
2. Select an environment from the environment dropdown located at the upper left of the VIP Dashboard.
3. Select “Code” from the sidebar navigation at the left of the screen.
4. Select “Deployments” from the submenu.

Deployment status messages

Progress for builds is displayed in real-time. The displayed status message for a deployment will change throughout the build and deploy process until it is complete.

• Pending: New changes have been detected and have been scheduled to be built and deployed.
• Building: The build is in progress.
• Build completed: The build has finished successfully.
• Build failed: The build has failed and the deployment process cannot proceed. An error_code will indicate a possible source of failure.
• Deploying: The deployment is in progress.
• Completed: The deployment has finished successfully.
• Failed: The deployment has failed. An error_code will indicate a possible source of failure.
• Cancelled: The process was manually canceled or canceled due to a newer deployment detected.

View details of a single deployment

Select a single deployment from the list view of the Deployments panel to view detailed information and logs for that deployment. All timestamps are formatted in Coordinated Universal Time (UTC).

The detailed view of a single deployment has a unique and shareable permalink URL and displays:

• The commit message
• The date and time in UTC of the commit
• A GitHub link to the commit or pull request
• The GitHub username for the user that made the commit
• Prepare logs display the duration of time for preparation steps to complete. Prepare logs are retained for 14 days.
• Build logs display the duration of time for the build to complete. Build logs are retained for 14 days. For Node.js environments, Build logs include the output from npm run build for each deploy. These are useful for debugging failing builds or deploys, and ensuring that the build step is running as expected.
• Deployment logs display the duration of time for the deployment to complete.

Troubleshooting

Canceled deploys

VIP Platform environments have multiple application containers. A complete deployment is a container image with the new code being built and then deployed across all containers. If two pull requests are merged to the same deploying branch in a very short amount of time, it is possible for the build of the second image to be ready to deploy before the first image has completed its deployment across all containers. If this occurs, the first deployment is marked as “Cancelled”, and the second merge will complete its deployment. Because merged code on Git contains all code previously merged to that branch, the deployed code from the second merged pull request will also include the changes made in the first merge.