Showing content from https://docs.oracle.com/en-us/iaas/Content/devops/using/deployment_pipelines.htm below:
Managing Deployment Pipelines
A deployment pipeline holds the requirements that must be satisfied to deliver a set of artifacts to the target environment.
Deployment pipelines contain different stages for automated deployment. Each stage is associated with certain actions in the pipeline. You can run the deployment pipeline based on one of the following release strategies:
- Blue-Green strategy: Involves running two identical production environments, blue and green, to reduce downtime and risk. Only one of the environments is active at any given moment, with the active environment running the production traffic. For example, if blue is active (production), then green is standby (staging) and vice versa. The active environment switches between blue and green environments during successive deployments. During deployment of a new version of the application, testing of the new version is done in the standby environment (green). If the testing is successful, then the traffic is shifted from the active environment (blue) to the standby environment. The validated version of the software is successfully deployed and now the green environment becomes active and blue is standby. The Blue-Green deployment strategy greatly reduces downtime in a continuous delivery model as the validation of new releases are done in standby environments without impacting the current production environment. Also, this strategy reduces risk of failure during deployment, as you can roll back to the previous successful version by simply shifting the production traffic.
- Canary strategy: Involves releasing initially the new version of the software to the canary environment. After successfully validating the release, then the software is released to the production environment. This strategy again like blue-green, reduces downtime and risk related to deployment. If the initial release fails, then it does not impact the production environment. Only successful and approved releases are pushed to production.
- Rolling strategy: A new version is deployed incrementally to the target environment by updating a set of hosts at a time. The update is validated before updating the next set of hosts. This process is repeated until rollout of the new version is complete.
Artifacts can be mutable or immutable. In the Artifact Registry, you can replace a mutable artifact. This is achieved by uploading an artifact to a mutable repository and assigning it a deleted artifact's name, or if an artifact with the same name exists, then the new artifact deletes and replaces the old one. The DevOps deployment pipeline fetches artifacts based on artifact path and version. For mutable artifacts, this can be the latest artifact found in the repository.
A Stage is an action in the deployment pipeline. DevOps service includes predefined stages, which could be readily used in a deployment pipeline. They are as follows:
You can add multiple stages to a pipeline. Stages can be added in a sequence or in parallel. You can remove any stage from the pipeline. When you do, the stage and its associated resources are deleted.
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4