post: gitops for devs - inlcude table of content

src/content/blog/gitops-for-devs-ci-cd.md

@@ -6,24 +6,36 @@ heroImage: 'https://bizkt.imgix.net/posts/gitopsfordev/ARGO_CICD_HERO.png'
 badge: "New"
 ---
 
-In the previous article, we discussed the codebase of the Album-App. In this article, we will discuss how we can implement CI/CD for the Album-App.
+In the previous article, we discussed the codebase of the Album-App.
+
+|           GitOps for Devs (3 Part Series)            |
+|---|
+| [GitOps for Devs - Part 01: Installation](./gitops-for-devs-installation) |
+| [GitOps for Devs - Part 2: Navigating the Code](./gitops-for-devs-the-code)     |
+| [GitOps for Devs - Part 03: CI/CD](./gitops-for-devs-ci-cd)  |
+
+In this article, we will discuss how we can implement CI/CD for the Album-App.
+
+![CI/CD Workflow](https://bizkt.imgix.net/posts/gitopsfordevs/ARGO_CICD.png)
+
+In the previous article, we discussed the codebase of the Album-App. This article will discuss how we can implement CI/CD for the Album-App.
 
 ![CI/CD Workflow](https://bizkt.imgix.net/posts/gitopsfordevs/ARGO_CICD.png)
 
 ## CI/CD Workflow
 
-There are number of ways to implement CI/CD workflow. But in summary we would:
+There are many ways to implement CI/CD workflow. But in summary,
 
 1. **Testing and Readiness Check**: Once the changes to the application code are thoroughly tested and verified for release, the process can proceed to the release phase.
 2. **Triggering the Release Pipeline**: This phase can be initiated manually or through an automated process, depending on your workflow and requirements.
-3. **Building and Pushing Docker Images**: The release process involves building the application code and pushing the resulting Docker images to the designated Docker registry or container repository.
+3. **Building and Pushing Docker Images**: The release process involves building the application code and pushing the resulting images to the designated Docker registry or container repository.
 4. **Updating Helm Chart Values**: Post-image creation, the Helm chart values in the **configuration repo** need an update with the new Docker image tag.
-5. **ArgoCD Trigger and Sync Process**: ArgoCD, being a continuous deployment tool,  detects changes within the configuration repository. ArgoCD compares the desired state (defined in Git repository) with the actual state of the cluster. Any disparities trigger the synchronization process to ensure alignment between the desired and actual state.
+5. **ArgoCD Trigger and Sync Process**: ArgoCD, being a continuous deployment tool,  detects changes within the configuration repository. ArgoCD compares the desired state (defined in the Git repository) with the actual state of the cluster. Any disparities trigger the synchronization process to ensure alignment between the desired and actual state.
 6. **Sync and Deployment**: Upon detecting changes, ArgoCD starts the sync process, pulling the updated configurations from the Git repository. ArgoCD applies these changes to the Kubernetes cluster, managing deployments, updates, or rollbacks as necessary to align the cluster with the desired state defined in the Helm charts.
 
 ## The pipeline
 
-The `album-app` 's release pipeline leverage GitHub actions. *_The pipeline is implemented in the application repository.*_
+The `album-app` 's release pipeline leverages GitHub actions. *The pipeline is implemented in the application repository.*
 
 ```yaml
 name: Build and Publish Docker Images
@@ -124,7 +136,7 @@ jobs:
           git push origin ${release_branch}
 
           # Body Content
-          pr_body="${{ github.repository }} ${app_name} release ${version}. Please note that this is a automated PR."
+          pr_body="${{ github.repository }} ${app_name} release ${version}. Please note that this is an automated PR."
 
           # Title Content
           pr_title="release: ${app_name} ${version}"
@@ -145,32 +157,29 @@ jobs:
 ### Jobs
 
 1. **build-and-publish**
-   - **Runs on:** Ubuntu latest
    - **Steps:**
      - **Checkout:** Fetches the repository code.
      - **Check tag name:** Extracts the tag name from the release.
      - **Check app name:** Retrieves the application name from the tag.
      - **Check Docker Image Version:** Determines the version of the Docker image.
      - **Login to GitHub Packages:** Authenticates to the GitHub Container Registry.
      - **Build and push image:** Uses Docker Build-Push Action to build and push the Docker image to the registry. It uses the extracted application name and version from earlier steps to tag the image appropriately.
-   - **Outputs:**
-     - **Version:** Docker image version.
-     - **App Name:** Application name used for the image.
 
 2. **deployment**
    - **Dependencies:** Depends on the completion of the 'build-and-publish' job.
-   - **Runs on:** Ubuntu latest
    - **Steps:**
      - **Checkout album-app-config:** Fetches the configuration repository (`CONFIG_REPO`) code.
      - **Update album-app-config repository:**
          - Retrieves the version and app name from the 'build-and-publish' job's outputs.
          - Creates a new release branch with the format `release/${app_name}_${version}`.
          - Modifies a Helm value file in the config repository with the new tag.
-         - Commits the changes and pushes to the remote repository.
+         - Commits the changes and pushes them to the remote repository.
          - Creates a pull request with automated content.
 
 Once the pull request has been merged, ArgoCD will detect the changes/disparities and start the sync process.
 
+<!-- {% youtube  <https://youtu.be/6bcoTivOVT4> %} -->
+
 ## Sync Policies
 
 You can use ArgoCD sync policies to control the sync behaviour.
@@ -186,13 +195,13 @@ spec:
       selfHeal: true
 ```
 
-*By the time you read this article, the selfHeal option may or may not be included. See [here](https://github.com/krishanthisera/album-app-config/blob/main/apps/templates/album-app.yaml)*
+*By the time you read this article, the `selfHeal` option may or may not be included. See [here](https://github.com/krishanthisera/album-app-config/blob/main/apps/templates/album-app.yaml)*
 
 See the [docs](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/#automated-sync-policy)
 
-## Sync Options
+### Sync Options
 
-Sync policies determine when to initiate a synchronization process (based on triggers or conditions), while **sync options** specify how the synchronization should occur, providing additional configurations and parameters for the synchronization process itself.
+**Sync options** specify how the synchronization should occur, providing additional configurations and parameters for the synchronization process itself.
 
 When using `auto-sync` in Argo CD, it currently applies all objects in an application, causing delays and strain on the API server, but enabling selective sync will only sync resources that are out-of-sync, reducing time and server load for applications with many objects.
 
@@ -203,10 +212,16 @@ spec:
     - ApplyOutOfSyncOnly=true
 ```
 
-<!-- {% youtube  <https://youtu.be/6bcoTivOVT4> %} -->
-
 See the [docs](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/)
 
 ## Conclusion
 
-Across these articles, we've gone from the basics to some advanced concepts in GitOps using ArgoCD. We started by setting up ArgoCD and deploying a sample app, giving a solid foundation. Then, we got our hands dirty, diving into the code intricacies. Lastly, we explored CI/CD implementation, an essential part of any developer's toolkit. Hopefully, these pieces have been a practical guide, making GitOps more accessible and showing its potential to streamline development workflows. As we close this series, keep experimenting and leveraging GitOps—it's a game-changer for modern development.
+Across these articles, we've gone from the basics to some advanced concepts in GitOps using ArgoCD. We started by setting up ArgoCD and deploying a sample app, giving a solid foundation. Then, we dive deep into the code intricacies. Lastly, we explored CI/CD implementation, an essential part of any developer's toolkit.
+
+Hopefully, these pieces have been a practical guide, making GitOps more accessible and showing its potential to streamline development workflows. As we close this series, keep experimenting and leveraging GitOps—it's a game-changer for modern development.
+
+|           GitOps for Devs (3 Part Series)            |
+|---|
+| [GitOps for Devs - Part 01: Installation](./gitops-for-devs-installation) |
+| [GitOps for Devs - Part 2: Navigating the Code](./gitops-for-devs-the-code)     |
+| [GitOps for Devs - Part 03: CI/CD](./gitops-for-devs-ci-cd)  |

src/content/blog/gitops-for-devs-installation.md

@@ -6,8 +6,15 @@ heroImage: 'https://bizkt.imgix.net/posts/gitopsfordevs/GitOps-for-devs.jpeg'
 badge: "New"
 ---
 
+
 GitOps is a hot topic in DevOps circles these days, and this article series aims to break down its core concepts starting from the basics. We'll kick things off by setting up ArgoCD a GitOps operator and deploying a sample application in this initial article. The following parts will dive deeper into configuration specifics.
 
+|           GitOps for Devs (3 Part Series)            |
+|---|
+| [GitOps for Devs - Part 01: Installation](./gitops-for-devs-installation) |
+| [GitOps for Devs - Part 2: Navigating the Code](./gitops-for-devs-the-code)     |
+| [GitOps for Devs - Part 03: CI/CD](./gitops-for-devs-ci-cd)  |
+
 ## GitOps 101
 
 GitOps automates modern cloud infrastructure setup by treating configuration files like code—similar to application source code. It ensures consistent and replicable infrastructure deployments, aligning with DevOps practices for quick code deployment, efficient cloud resource management, and adaptation to rapid development cycles.
@@ -36,31 +43,29 @@ In a push-based GitOps workflow, the deployment and synchronization are initiate
 
 **GitOps Operator:** An external system, like a CI/CD tool, monitors the codebase and, upon changes, triggers the GitOps workflow.
 
-When changes are made to the Application repo, developers create a pull request or directly commit changes to the application repo, the CI/CD pipeline is triggered. In this context, a new container image(s) is pushed to the container registry.
+Developers make changes to the Application Repo, either by creating pull requests or directly committing alterations to the codebase. As a result, a CI/CD pipeline is triggered, initiating the creation and pushing of new container images to the container registry.
 
-Afterwards, the image or image tag is updated in the config repo. _This could be a fully automated commit or a PR which intended to manually merge._
+Subsequently, these newly generated images or their tags are updated in the Config Repo. This step could be executed through an automated commit or by means of a pull request intended for manual merging.
 
-The GitOps operator or tool pulls the latest configuration from the Git repository and deploys or updates the infrastructure and applications based on the new configuration. The operator continuously monitors the config repo for subsequent changes.
+The GitOps operator, an external system like a CI/CD tool, closely monitors the codebase for any changes. Once alterations to the Config Repo are detected, the GitOps operator pulls the most recent configuration from the repository. It then proceeds to deploy or update the infrastructure and applications based on this updated configuration. This process is continuous, as the operator consistently monitors the Config Repo for any further changes, ready to repeat the deployment cycle when new updates are detected.
 
 #### Pull-based GitOps Workflow
 
 In a pull-based GitOps workflow, the deployment and synchronization of the infrastructure and applications are triggered by changes in the Git repository.
 
 ![GitOps Pull](https://bizkt.imgix.net/posts/gitopsfordevs/ARGO_GITOPS_PULL.png)
 
-**Application Repo:** Contains the application source code, which is intended to package and later deploy.
-
-**Config Repo:** The desired state of the infrastructure and applications is defined in this repository, often through declarative configuration files like YAML.
+Similar to the push-based workflow, there are two primary repositories: the **Application Repo** and the **Config Repo**.
 
 **GitOps Operator:** The GitOps operator or tool continuously monitors the Git repository for changes. This operator usually sits closely with infrastructure, in this case, deployed in a Kubernetes cluster.
 
-When changes are made to the Application repo, developers create a pull request or directly commit changes to the Application repo, the CI/CD pipeline is triggered. In this context, a new container image(s) is pushed to the container registry.
+Developers, again, make changes to the **Application Repo**, either by creating pull requests or directly committing changes to the codebase. This triggers a CI/CD pipeline, resulting in the creation and pushing of new container images to the container registry.
 
-Afterwards, the image or image tag is updated in the config repository. _This could be a fully automated commit or a PR which intended to manually merge._
+Following this, the updated image or its tag is modified in the Config Repo, either through an automated commit or a pull request for manual merging.
 
-The GitOps operator detects the changes and pulls the latest configuration from the Git repository. The operator then deploys or updates the infrastructure and applications based on the new configuration in the Git repository.
+However, the GitOps operator's role is distinct in this workflow. Instead of external initiation, the GitOps operator constantly monitors the Config Repo for any changes. As soon as changes are detected, the operator pulls the latest configuration from the repository and proceeds to deploy or update the infrastructure and applications based on this revised configuration.
 
-The GitOps operator continues to monitor the Git repository for any further changes, repeating the process when new updates are detected.
+Similar to the push-based workflow, this process remains continuous, with the GitOps operator continuously monitoring the Config Repo for any subsequent changes, ready to redeploy or update as needed.
 
 ## Install minikube
 
@@ -221,7 +226,7 @@ ArgoCD has its own CLI as well, follow [this](https://argo-cd.readthedocs.io/en/
 For this tutorial, I am using two repos:
 
 - **Config**: <https://github.com/krishanthisera/album-app-config>
-- **Application**:  <https://github.com/krishanthisera/album-app-config>
+- **Application**:  <https://github.com/krishanthisera/album-app>
 
 As the names suggest, the config repo contains the infrastructure configuration, in this case, helm charts, while the application repo contains the code for **frontend** and **backend**.
 
@@ -317,3 +322,9 @@ Forwarding from [::1]:8090 -> 3000
 Now that we have installed the Album App, let's dive deep into the ArgoCD-specific configuration.
 
 Stay tuned. To be continued...
+
+|           GitOps for Devs (3 Part Series)            |
+|---|
+| [GitOps for Devs - Part 01: Installation](./gitops-for-devs-installation) |
+| [GitOps for Devs - Part 2: Navigating the Code](./gitops-for-devs-the-code)     |
+| [GitOps for Devs - Part 03: CI/CD](./gitops-for-devs-ci-cd)  |

src/content/blog/gitops-for-devs-the-code.md

@@ -5,7 +5,17 @@ pubDate: "Dec 31 2023"
 heroImage: 'https://bizkt.imgix.net/posts/gitopsfordevs/GitOps-for-devs-code.jpeg'
 badge: "New"
 ---
-We're continuing our exploration of GitOps with ArgoCD. In the first part, we got a grasp of GitOps basics and set up an example app called Album-App. Now, let's explore the repositories that drive this application:
+
+
+We're continuing our exploration of GitOps with ArgoCD. In the first part, we got a grasp of GitOps basics and set up an example app called Album-App.
+
+|           GitOps for Devs (3 Part Series)            |
+|---|
+| [GitOps for Devs - Part 01: Installation](./gitops-for-devs-installation) |
+| [GitOps for Devs - Part 2: Navigating the Code](./gitops-for-devs-the-code)     |
+| [GitOps for Devs - Part 03: CI/CD](./gitops-for-devs-ci-cd)  |
+
+Now, let's explore the repositories that drive this application:
 
 ## The Two Repositories
 
@@ -167,7 +177,7 @@ The frontend and backend ArgoCD Application resources point to their respective
 
 ## Frontend and Backend Helm Charts
 
-These Helm charts define how the frontend and backend applications will be deployed on Kubernetes. They contain configuration details encapsulated within `values.yaml` files.
+These Helm charts define how the frontend and backend applications will be deployed on Kubernetes. They contain configuration details encapsulated within `values.yaml`. files.
 
 ```yaml
 replicaCount: 1
@@ -178,7 +188,6 @@ image:
   tag: "v1.3.2" # Important: This tag signifies the version of the backend application.
   containerPort: 8080
 
-
 service: 
   name: album-app-backend
   port: 8080
@@ -193,3 +202,9 @@ During the release process of the application, the `tag` value will be replaced
 Part 3 of the article series will cover the release process including CI/CD pipelines.
 
 Stay tuned!
+
+|           GitOps for Devs (3 Part Series)            |
+|---|
+| [GitOps for Devs - Part 01: Installation](./gitops-for-devs-installation) |
+| [GitOps for Devs - Part 2: Navigating the Code](./gitops-for-devs-the-code)     |
+| [GitOps for Devs - Part 03: CI/CD](./gitops-for-devs-ci-cd)  |