GitOps: Difference between revisions
| (3 intermediate revisions by the same user not shown) | |||
| Line 6: | Line 6: | ||
* [[Git]] | * [[Git]] | ||
=Overview= | =Overview= | ||
GitOps is a way of implementing [[ | GitOps is a way of implementing [[Continuous_Delivery#Overview|Continuous Delivery]] for cloud native applications, in which the Git source repository also serves as [[Continuous_Delivery#Delivery_Repository|delivery repository]] for infrastructure code. It focuses on a developer-centric experience when operating infrastructure, by using tools developers are already familiar with, including Git and Continuous Delivery tools. The core idea of GitOps is having a Git repository that always contains declarative descriptions of the infrastructure currently desired in the production environment and an automated process to make the production environment match the described state in the repository. If you want to deploy a new application or update an existing one, you only need to update the repository - the automated process handles everything else. It’s like having cruise control for managing your applications in production. | ||
GitOps does not prescribe an approach to testing and delivering infrastructure code, but it is compatible with using a pipeline to deliver code. | |||
GitOps discourages the use of delivery artifacts, instead promoting code changes by merging them to the source code branches. | |||
=Organizatorium= | |||
<font color=darkkhaki> | |||
TO PROCESS: | |||
* https://www.weave.works/blog/gitops-operations-by-pull-request | |||
</font> | |||
Latest revision as of 00:00, 31 January 2022
External
Internal
Overview
GitOps is a way of implementing Continuous Delivery for cloud native applications, in which the Git source repository also serves as delivery repository for infrastructure code. It focuses on a developer-centric experience when operating infrastructure, by using tools developers are already familiar with, including Git and Continuous Delivery tools. The core idea of GitOps is having a Git repository that always contains declarative descriptions of the infrastructure currently desired in the production environment and an automated process to make the production environment match the described state in the repository. If you want to deploy a new application or update an existing one, you only need to update the repository - the automated process handles everything else. It’s like having cruise control for managing your applications in production.
GitOps does not prescribe an approach to testing and delivering infrastructure code, but it is compatible with using a pipeline to deliver code.
GitOps discourages the use of delivery artifacts, instead promoting code changes by merging them to the source code branches.
Organizatorium
TO PROCESS: