# Cloud Native Application Delivery

Every application starts its lifecycle with code that is written.

With services getting smaller and deployments getting more frequent, a logical and important step was the automation of the deployment process. The DevOps movement has highlighted the importance of frequent and rapid deployments. In traditional setups, a deployment would include developers and administrators, a lot of error-prone manual steps and the constant fear that something would break.

**Automation** is the key to overcoming these barriers, and today we know and use the principles of Continuous Integration/Continuous Delivery (CI/CD), which describe the different steps in the deployment of an application, configuration or even infrastructure.

**Continuous Integration** is the first part of the process and describes the permanent building and testing of the written code. High automation and usage of version control allows multiple developers and teams to work on the same code base.

**Continuous Delivery** is the second part of the process and automates the deployment of the pre-built software. In cloud environments, you will often see that software is deployed to Development or Staging environments, before it gets released and delivered to a production system.

Every time a new revision of your code is ready to be deployed, the pipeline starts to execute scripts that build your code, run tests, deploy them to servers and even perform security and compliance checks.

**GitOps**

GitOps takes the idea of Git as the single source of truth a step further and integrates the provisioning and change process of infrastructure with version control operations.

If code was branched and should be merged back into the main branch, you can create a merge or pull request that can be reviewed by other developers before actually merging it. This has been a best practice for a long time in software development, and also includes running a CI pipeline for every change that should be made. In GitOps, these merge requests are used to manage infrastructure changes.

There are two different approaches how a CI/CD pipeline can implement the changes you want to make:

* **Push-based**: The pipeline is started and runs tools that make the changes in the platform. Changes can be triggered by a commit or merge request.
* **Pull-based**: An agent watches the git repository for changes and compares the definition in the repository with the actual running state. If changes are detected, the agent applies the changes to the infrastructure.

Two examples of popular GitOps frameworks that use the pull-based approach are Flux and ArgoCD. ArgoCD is implemented as a Kubernetes controller, while Flux is built with the GitOps Toolkit, a set of APIs and controllers that can be used to extend Flux, or even build a custom delivery platform.

**Kubernetes** is particularly well suited for GitOps, since it provides an API and is designed for declarative provisioning and changes of resources right from the beginning.

The network that enables communication and networking between pods in Kubernetes is called the pod network. It allows pods to communicate with each other regardless of the node they are running on, facilitating seamless networking within the cluster.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfv6X6GqPfeYLVclxgwepg7Zx3ZaYYl9crU4qJSJrEnwuQgNwNG0vbhnS4DM2ceZ1h_AdkSHQn8GsTVVNRqcOtkQve8S2naQeNgvyZQI46rNKiZyE_8yXEelrRonlZEsYLVKJiU?key=j3DY1ywyYMcgEDcgb1K_i91R" alt=""><figcaption></figcaption></figure>

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://abdelfare.gitbook.io/notes/kubernetes/kcna-notes/cloud-native-application-delivery.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.