After CI passes, decide where the artifact is stored, who approves it and which identifier is deployed. A clear delivery path makes it possible to identify the version to restore after a failure. Follow the same tested artifact through each environment rather than rebuilding it for each stage.
CD is used to mean both continuous delivery and continuous distribution. Delivery allows for human approval to be reflected in operations while continuously preparing a deployable state, while deployment is an approach in which changes that have passed a set inspection are automatically reflected in operations. Whatever wording you choose, document the actual approval path.
Git · GitOps All Series · 19 / 24
On this page
Promote tested results without recreating them
코드 커밋 → CI 테스트 → 결과물 보관 → 개발 환경 검증
↓
승인 → 운영 반영If you recreate a production build from successful sources in the development environment, results may vary due to dependencies or differences in build timing. It is easier to explain what has been verified by promoting the same result with environment-specific settings. However, a fully reproducible build requires additional management of lock files, tool chains, and build environments.
app.zip in Part 17 is a learning output that bundles Git trace files. Deploying this as a service requires more execution environment and process management. The following GitOps exercise does not pretend to have deployed this Python app, but only checks the state of Kubernetes with the official nginx image.
Tag is the name, digest is the content identifier
Tags like nginx:stable-alpine can be moved to other images later. digest identifies a specific manifest or image index in the registry based on its content. By recording digest in the distribution settings, you can reduce the ambiguity of “same tag but different images on each server”.
docker buildx imagetools inspect nginx:stable-alpineDistinguish between the parent digest of the output and the platform-specific manifest digest. The multi-platform index digest points to the image appropriate for the platform of the execution node. If the result is built directly, the digest is checked and recorded in the registry after the push is completed. We do not create and insert random SHA strings.
image: registry.example.com/team/app@sha256:VERIFIED_DIGESTThe line above is a grammar example. VERIFIED_DIGEST must be replaced with the 64-digit hash you actually verified. Fixing does not automatically result in security updates, so review new images and digest change PRs as part of your operating procedures.
What to check when approving
| Information to check | Why you need it |
|---|---|
| Source commit and CI execution | Link which changes passed which tests |
| Result name and digest/checksum | Verify that the deployment target is the same as the test target |
| Change settings and scope of permissions | Identify operational impacts beyond code |
| Health status and criteria for return | Determine failure and prepare recovery path |
One approve button does not create quality. Divide development and operations credentials and grant only the scope necessary for deployment tasks. We also check whether arbitrary code executed by an external PR can read the operational secret value.
Successful deployment and normal service are different
Just because a process starts or the Kubernetes Deployment becomes Available does not mean that all user functionality is normal. View readiness, HTTP responses, mission-critical requests, and error rates together. Observation times and outage criteria are determined based on service characteristics and the example figures in this series are not copied on an operational basis.
Even though code images can be rolled back to a previous digest, destructive schema changes to the database may not be recovered in the same way. Prepare separate backward compatible migration, backup, feature flag and data recovery plans. Be specific about what “rollbackable” includes.
GitHub’s environment approval function can be checked at Deployment environment management, and digest inquiry can be found at Docker imagetools inspect. From the next part, we will create a GitOps repository that manages the status to be deployed in Git.
Previous · [Git and GitOps 18] Connect Gitea and Jenkins: Credentials and Jenkinsfile · Next · [Git and GitOps 20] Apply GitOps Principles and Separate App and Deployment Repositories · Serial list and example files
.jpg){kind=link}