The examples below illustrate the use of Humanitec Pipelines to realize a particular capability.
Notify Slack Channel Of Failed Deployments
Deployment Pipelines
Humanitec Pipelines supports an
http action which is able to send external requests with data from the Pipeline execution. This can be used to trigger or notify external systems. One example of this is to notify a channel in Slack or raise a support request or ticket.
(...)
Prevent Direct Deployment To Production
Deployment Pipelines
In the “
promote between environments” example, a Pipeline is used to promote a Workload from development to production. To ensure that all changes to production have first been tested in development, it may be necessary to block direct deployment of Deltas to production. Deployment request Matching Criteria can be used for this.
(...)
Promote Between Environments After Approval
Artefact Automation Pipelines
While automated Continuous Delivery of deployments to a production Environment may be a goal, you may come across scenarios in which a manual approval must be given by a user or external system before promoting a sensitive component or change into an Environment.
(...)
Run Automated Tests After Deployment
Deployment Pipelines
When the Platform Orchestrator deploys changes into an Environment, the Deployment status indicates whether it successfully provisioned associated resources and configured the Workloads. It does not necessarily imply that the Applications are healthy or that the desired functionality is available to end users. This is why a major benefit of Continuous Delivery Pipelines is the ability to perform health checks and run a suite of tests against the running application in a pre-production or even production Environment.
(...)
Run Tests Before Cloning To Production
Api Triggered Pipelines
In some environments, continuously deploying all changes from development to production may not be desirable. It may be more important to promote on a manually (or externally) triggered schedule.
(...)
Wait For Workloads Readiness Or Fail
Deployment Pipelines
When the Platform Orchestrator deploys changes into an Environment, the Deployment status indicates whether it successfully provisioned associated resources and configured the Workloads. It does not necessarily imply that the Workloads are healthy or that the desired functionality is available to end users. The Pipeline will also be successful in scenario where the Workload will never be
Ready, for example when the container image doesn't exist (ImagePullBackOff), or when an admission controller is blocking the deployment in the Kubernetes cluster, etc.
(...)