Triggering a deployment
PipeCD uses Git as a single source of truth; all application resources are defined declaratively and immutably in Git. Whenever a developer wants to update the application or infrastructure, they will send a pull request to that Git repository to propose the change. The state defined in Git is the desired state for the application and infrastructure running in the cluster.
PipeCD applies the proposed changes to running resources in the cluster by triggering needed deployments for applications. The deployment mission is syncing all running resources of the application in the cluster to the state specified in the newest commit in Git.
By default, when a new merged pull request touches an application, a new deployment for that application will be triggered to execute the sync process. But users can configure the application to control when a new deployment should be triggered or not. For example, using
onOutOfSync to enable the ability to attempt to resolve
OUT_OF_SYNC state whenever a configuration drift has been detected.
Configuration for the trigger used to determine whether we trigger a new deployment. There are several configurable types:
onCommit: Controls triggering new deployment when new Git commits touched the application.
onCommand: Controls triggering new deployment when received a new
onOutOfSync: Controls triggering new deployment when application is at
onChain: Controls triggering new deployment when the application is counted as a node of some chains.
See Configuration Reference for the full configuration.
After a new deployment was triggered, it will be queued to handle by the appropriate
piped. And at this time the deployment pipeline was not decided yet.
piped schedules all deployments of applications to ensure that for each application only one deployment will be executed at the same time.
When no deployment of an application is running,
piped picks queueing one to plan the deploying pipeline.
piped plans the deploying pipeline based on the application configuration and the diff between the running state and the specified state in the newest commit.
- when the merged pull request updated a Deployment’s container image or updated a mounting ConfigMap or Secret,
pipedplanner will decide that the deployment should use the specified pipeline to do a progressive deployment.
- when the merged pull request just updated the
pipedplanner will decide to use a quick sync to scale the resources.
You can force
piped planner to decide to use the QuickSync or the specified pipeline based on the commit message by configuring CommitMatcher in the application configuration.
After being planned, the deployment will be executed as the decided pipeline. The deployment execution including the state of each stage as well as their logs can be viewed in realtime at the deployment details page.
A Running Deployment at the Deployment Details Page
As explained above, by default all deployments will be triggered automatically by checking the merged commits but you also can manually trigger a new deployment from web UI.
By clicking on
SYNC button at the application details page, a new deployment for that application will be triggered to sync the application to be the state specified at the newest commit of the master branch (default branch).
Application Details Page
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.