From cicd
Designs Cloud Deploy delivery pipelines and manages releases for Cloud Run or GKE apps with multi-environment deployments, canary strategies, rollbacks, and automations.
npx claudepluginhub gemini-cli-extensions/cicd --plugin cicdThis skill uses the workspace's default tool permissions.
This skill encompasses the entire lifecycle of Cloud Deploy for a user, from designing and creating delivery pipelines to managing releases and debugging release failures.
Orchestrates multi-stage deployment pipelines with Kubernetes, CI/CD platforms, and strategies like blue-green, canary, rolling updates across dev/staging/prod.
Implements modern CI/CD pipelines, GitOps workflows with ArgoCD and Flux, and zero-downtime deployment automation across GitHub Actions, GitLab, Jenkins, and cloud platforms.
Designs and implements Google Cloud CI/CD pipelines using best practices, patterns, and references like Cloud Build YAML. For building pipelines, GCP architecture, or migrations.
Share bugs, ideas, or general feedback.
This skill encompasses the entire lifecycle of Cloud Deploy for a user, from designing and creating delivery pipelines to managing releases and debugging release failures.
All Workflows require the clouddeploy.googleapis.com API to be enabled.
This workflow provides steps for designing a Cloud Deploy DeliveryPipeline.
<PROJECT_ID>. Ask the user for values first.Required Context: Before generating ANY configuration for this workflow, you MUST have the following values. Ask the user strictly for any missing information:
us-central1).DeliveryPipeline and Target resources.Target resources in a clouddeploy.yaml file.
references/configure-targets.md as a reference when generating the resource YAML.[app-name]-[env]) to prevent resource name collisions when multiple applications are deployed to different environments. For example, if the user wants to deploy an application named "hello-world" to test and prod environments, then use "hello-world-test" and "hello-world-prod" as the Target IDs.DeliveryPipeline in the clouddeploy.yaml file.
references/configure-pipelines.md as a reference when generating the resource YAML.DeliveryPipeline ID.Automation resources in the clouddeploy.yaml file.references/configure-automations.md as a reference when generating the resource YAML.Ensure that the clouddeploy.yaml file is valid. See https://docs.cloud.google.com/deploy/docs/config-files for the schema.
Run the following command to create the Cloud Deploy DeliveryPipeline and associated resources, using the values collected in Step 0:
gcloud deploy apply --file=clouddeploy.yaml --region=<REGION> --project=<PROJECT_ID>
Required Context: Before generating a skaffold.yaml file, you MUST know if the user has manifests for the runtime they are deploying to.
references/basic-cloudrun-manifests.md as a reference.Deployment and Servicemanifest. Use references/basic-k8s-manifests.md as a reference.skaffold.yaml file required to create a Cloud Deploy Release for the DeliveryPipeline.
references/configure-skaffold.md as a reference when generating the skaffold.yaml file.Use references/iam-permissions.md as a reference to set up the necessary IAM permissions based on the DeliveryPipeline defined.
Cloud Deploy integrates with Google Cloud Observability to provide metrics analysis when deploying an application. When the application is deployed, Cloud Deploy will monitor alert policies defined in Google Cloud Observability for any incidents that were triggered after the application was deployed.
This feature can be used alongside automation to enable automatic rollbacks if the application deployment triggers alert policies.
This section covers how to update the user's DeliveryPipeline to leverage this feature.
A DeliveryPipeline MUST already be defined or being designed in the current context.
Cloud Deploy requires the Google Cloud Observability alerting policies to be defined before they can be referenced in the DeliveryPipeline.
references/basic-cloudrun-alerts.md as a reference.DeliveryPipeline definition in the clouddeploy.yaml file to include analysis configuration.
references/configure-pipelines.md as a reference when updating the DeliveryPipeline definition.Ensure that the clouddeploy.yaml file is valid. See https://docs.cloud.google.com/deploy/docs/config-files for the schema.
Run the following command to update the Cloud Deploy DeliveryPipeline:
gcloud deploy apply --file=clouddeploy.yaml --region=<REGION> --project=<PROJECT_ID>
Use references/iam-permissions.md as a reference to set up the necessary IAM permissions for analysis.
This section covers the various aspects of managing Cloud Deploy Release resources.
In order to manage releases, a DeliveryPipeline MUST already be defined and configured in Cloud Deploy. Determine whether a delivery pipeline is defined by checking for a clouddeploy.yaml file and checking if the resources exist in Cloud Deploy or ask the user directly.
Required Context:
DeliveryPipeline.DeliveryPipeline (e.g., us-central1).DeliveryPipeline ID.Use case: The user wants to deploy a new version of their application.
Required Context: Before creating a Release, you MUST know whether the users runtime manifests are using a placeholder for the container image and the value of the placeholder. This is CRITICAL for build artifact substitution in Cloud Deploy. Check the users runtime manifests or ask the user directly. See examples in references/basic-cloudrun-manifests.md and references/basic-k8s-manifests.md.
Run the following command to create a Release for the DeliveryPipeline:
gcloud deploy releases create release-$DATE-$TIME --delivery-pipeline=<DELIVERY_PIPELINE_ID> --region=<REGION> --project=<PROJECT_ID>
If the user is leveraging build artifact substitution with a placeholder in the image field of the runtime manifests then use the --images flag:
gcloud deploy releases create release-$DATE-$TIME --delivery-pipeline=<DELIVERY_PIPELINE_ID> --region=<REGION> --project=<PROJECT_ID> --images <IMAGE_PLACEHOLDER>=<IMAGE_URI>
CRITICAL: If the skaffold.yaml is not in the current directory, use the --source flag to specify the directory where the skaffold.yaml file is located.
Reference documenation for gcloud deploy releases create: https://docs.cloud.google.com/sdk/gcloud/reference/deploy/releases/create.
Use case: The user wants to promote the application to the next target environment in the DeliveryPipeline progression sequence.
Run the following command to promote a Release to the next target in the DeliveryPipeline progression sequence:
gcloud deploy promote --release=<RELEASE_ID> --delivery-pipeline=<DELIVERY_PIPELINE_ID> --region=<REGION> --project=<PROJECT_ID>
TIP: Use a short <RELEASE_ID> since the command will auto-generate a Rollout ID (with a 63 character limit) in the format: <RELEASE_ID>-to-<TARGET_ID>.
Reference documentation for gcloud deploy releases promote: https://docs.cloud.google.com/sdk/gcloud/reference/deploy/releases/promote.
Use case: Monitor the status of a release across a DeliveryPipeline.
Monitoring a release across a DeliveryPipeline consists of checking the status of both the Release resource and its child Rollout resource(s). Always ensure that the Release has completed successfully before checking the status of the Rollout.
Get the release to determine which of the target renders failed and inspect the failure message and failure cause. Additionally the target renders contain a Cloud Build reference where the target render was executed. Retrieve the build logs to determine the root cause of the failure.
Get the rollout to determine which of the jobs failed and inspect the failure message and failure cause. Additionally the Rollout contains a Cloud Build reference where the failed job was executed. Retrieve the build logs to determine the root cause of the failure.