{"id":39349699,"url":"https://github.com/saenyakorn/monorepo-versioning-gitops","last_synced_at":"2026-01-18T02:27:50.731Z","repository":{"id":65419137,"uuid":"583253159","full_name":"saenyakorn/monorepo-versioning-gitops","owner":"saenyakorn","description":"Versioning workflows on Monorepo and deploy the services with GitOps concept","archived":false,"fork":false,"pushed_at":"2023-05-06T10:39:33.000Z","size":1807,"stargazers_count":11,"open_issues_count":2,"forks_count":1,"subscribers_count":1,"default_branch":"beta","last_synced_at":"2023-05-06T11:22:26.090Z","etag":null,"topics":["changeset","cicd","continuous-delivery","continuous-deployment","deployment","gitops","monorepo","turborepo","versioning","versioning-workflow"],"latest_commit_sha":null,"homepage":"","language":"Dockerfile","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/saenyakorn.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2022-12-29T08:13:41.000Z","updated_at":"2023-05-02T16:10:46.000Z","dependencies_parsed_at":"2023-02-12T17:15:45.597Z","dependency_job_id":null,"html_url":"https://github.com/saenyakorn/monorepo-versioning-gitops","commit_stats":null,"previous_names":[],"tags_count":null,"template":null,"template_full_name":null,"purl":"pkg:github/saenyakorn/monorepo-versioning-gitops","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/saenyakorn%2Fmonorepo-versioning-gitops","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/saenyakorn%2Fmonorepo-versioning-gitops/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/saenyakorn%2Fmonorepo-versioning-gitops/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/saenyakorn%2Fmonorepo-versioning-gitops/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/saenyakorn","download_url":"https://codeload.github.com/saenyakorn/monorepo-versioning-gitops/tar.gz/refs/heads/beta","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/saenyakorn%2Fmonorepo-versioning-gitops/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28526569,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-18T00:39:45.795Z","status":"online","status_checked_at":"2026-01-18T02:00:07.578Z","response_time":98,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["changeset","cicd","continuous-delivery","continuous-deployment","deployment","gitops","monorepo","turborepo","versioning","versioning-workflow"],"created_at":"2026-01-18T02:27:50.609Z","updated_at":"2026-01-18T02:27:50.702Z","avatar_url":"https://github.com/saenyakorn.png","language":"Dockerfile","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Monorepo Versioning with GitOps \u003c!-- omit in toc --\u003e\n\nAs [Microservices architecture][1] becomes popular recently, [Monorepo][2] is also in trend right now as a software development concept. If you don't know what a Monorepo is, I recommend you to read [Why you should use Monorepo and why you should not][3] first.\n\nOne of the biggest challenges of a Monorepo is how to optimize the deployment pipeline and versioning for your apps and packages. In this demonstration, I'll show you how.\n\n# Table of Contents \u003c!-- omit in toc --\u003e\n\n- [Real use cases](#real-use-cases)\n- [Blog posts](#blog-posts)\n  - [For Thais](#for-thais)\n- [Tools I used](#tools-i-used)\n- [Why versioning is important](#why-versioning-is-important)\n- [What is ArgoCD](#what-is-argocd)\n- [Demo Architecture](#demo-architecture)\n- [Deployment and Versioning Demo](#deployment-and-versioning-demo)\n  - [Dev Deployment](#dev-deployment)\n  - [Staging (Beta) Deployment](#staging-beta-deployment)\n  - [Production Deployment](#production-deployment)\n- [Sequence Diagram](#sequence-diagram)\n  - [Scenario 1: Develop new features and deploy to dev environment](#scenario-1-develop-new-features-and-deploy-to-dev-environment)\n  - [Scenario 2: Deploy the new feature to staging environment](#scenario-2-deploy-the-new-feature-to-staging-environment)\n  - [Scenario 3: Deploy the new feature to production environment](#scenario-3-deploy-the-new-feature-to-production-environment)\n- [How can I setup the CI/CD pipeline for my monorepo?](#how-can-i-setup-the-cicd-pipeline-for-my-monorepo)\n  - [Setup Changesets](#setup-changesets)\n  - [Setup ArgoCD to your cluster](#setup-argocd-to-your-cluster)\n    - [Quick start](#quick-start)\n- [FAQ](#faq)\n- [Reference](#reference)\n\n# Real use cases\n\n- [CU Get Reg](https://github.com/thinc-org/cugetreg)\n\n# Blog posts\n\n## For Thais\n\n- [มาทำ Versioning + GitOps + K8s บน Monorepo กันเถอะ! Part I](https://medium.com/thinc-org/%E0%B8%A1%E0%B8%B2%E0%B8%97%E0%B8%B3-versioning-gitops-k8s-%E0%B8%9A%E0%B8%99-monorepo-%E0%B8%81%E0%B8%B1%E0%B8%99%E0%B9%80%E0%B8%96%E0%B8%AD%E0%B8%B0-part-i-b98bb35c1010) - **Introduction**: How important is Monorepo, versioning and GitOps? And what are the challenges?\n\n- [มาทำ Versioning + GitOps + K8s บน Monorepo กันเถอะ! Part II](https://medium.com/thinc-org/%E0%B8%A1%E0%B8%B2%E0%B8%97%E0%B8%B3-versioning-gitops-k8s-%E0%B8%9A%E0%B8%99-monorepo-%E0%B8%81%E0%B8%B1%E0%B8%99%E0%B9%80%E0%B8%96%E0%B8%AD%E0%B8%B0-part-ii-2a5e180fbf0f) - **Versioning Tutorial**: What is versioning and how to do it in Monorepo? What tools can we use?\n\n- [มาทำ Versioning + GitOps + K8s บน Monorepo กันเถอะ! Part III](https://medium.com/thinc-org/%E0%B8%A1%E0%B8%B2%E0%B8%97%E0%B8%B3-versioning-gitops-k8s-%E0%B8%9A%E0%B8%99-monorepo-%E0%B8%81%E0%B8%B1%E0%B8%99%E0%B9%80%E0%B8%96%E0%B8%AD%E0%B8%B0-part-iii-6598e57084ed) - **A whole development process**: How to work with Gitflow and where to apply versioning and GitOps in our workflows?\n\n- [มาทำ Versioning + GitOps + K8s บน Monorepo กันเถอะ! Part IV](https://medium.com/thinc-org/%E0%B8%A1%E0%B8%B2%E0%B8%97%E0%B8%B3-versioning-gitops-k8s-%E0%B8%9A%E0%B8%99-monorepo-%E0%B8%81%E0%B8%B1%E0%B8%99%E0%B9%80%E0%B8%96%E0%B8%AD%E0%B8%B0-part-iv-5fc9771e85c0) - **The Implementation**: How to implement the whole development process in Part III? What each step of the workflow is?\n\n- 🚧 มาทำ Versioning + GitOps + K8s บน Monorepo กันเถอะ! Part V - **How to pre-release**: How to pre-release your packages and apps? What is the workflow? It's specially difficult when you have a monorepo.\n\n# Tools I used\n\n- Monorepo management tool - [Turborepo][4]\n- Versioning tool - [Changesets][5] and [Changesets Action][6]\n- CI/CD tool - [GitHub Actions][7]\n- GitOps tool - [ArgoCD][8]\n\n# Why versioning is important\n\nVersioning is important because it helps you track changes in your apps and packages from the CHANGELOG. It also enables you to understand what's new in the latest version of your apps and packages, and it indicates the type of changes made (such as feature, bug fix, breaking change, etc.).\n\nTo learn more about versioning, visit: https://en.wikipedia.org/wiki/Software_versioning.\n\n# What is ArgoCD\n\n[ArgoCD][8] is a [GitOps](https://about.gitlab.com/topics/gitops/) tool that helps you manage your apps and packages in K8s using a declarative approach. You can learn more about ArgoCD at [https://argoproj.github.io/argo-cd/][8].\n\nArgoCD follows the pull model, which means that it pulls the image with a specific version defined in the K8s manifest file.\n\nIn contrast, traditional CI/CD pipelines follow the push model. This means that you must apply the K8s manifest file to the cluster after the CI/CD pipeline is finished. Additionally, you may need to set up credentials for the CI/CD pipeline to access the cluster, which can lead to security issues.\n\nTo learn more about GitOps and the differences between the push model and the pull model, here [https://faun.pub/gitops-comparison-pull-and-push-88fcbaadfe45][9].\n\n# Demo Architecture\n\nHere is the application architecture for this repository. It consists of three applications and one shared package. The shared package contains code that is common across the applications except api, while each of the three applications has its own unique functionality. The architecture is designed to be simple and easy to understand, making it a great starting point for developers who are new to the repository.\n\n```mermaid\n---\ntitle: Apps\n---\nclassDiagram\n    Web \u003c|-- UI\n    Docs \u003c|-- UI\n    class api\n```\n\n# Deployment and Versioning Demo\n\nVersionning and deployment workflow is based on [GitFlow][9], which is a branching model for Git.\n\nAssume that you have 3 application's environments.\n\n1. **Production** - This environment is for end-users and is located in the `main` branch.\n2. **Staging (Beta)** - This environment is for testing new features and bug fixes before releasing them to production. It's located in the `beta` branch.\n3. **Development** - This environment allows developers to test their code by deploying it for testing purposes without reviewing before opening PRs to `beta`. It's located in the `dev` branch.\n\n```mermaid\n%%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'rotateCommitLabel': false}}}%%\ngitGraph\n   commit id: \"release v1.0.0\" tag: \"v1.0.0\"\n   branch beta\n   checkout beta\n   commit id: \"branch from v1.0.0\"\n   branch feature-1\n   branch feature-2\n   branch dev\n   checkout feature-1\n   commit id: \"develop feature 1\"\n   checkout dev\n   merge feature-1 id: \"merge feature-1 into dev\"\n   checkout feature-2\n   commit id: \"develop feature 2\"\n   checkout dev\n   merge feature-2 id: \"merge feature-2 into dev\"\n   checkout beta\n   merge feature-1 id: \"merge feature-1 into beta\"\n   merge feature-2 id: \"merge feature-2 into beta\"\n   branch changeset/beta\n   checkout changeset/beta\n   commit id: \"versioning beta\"\n   checkout beta\n   merge changeset/beta id: \"merge changeset/beta into beta\" tag: \"v1.1.0-beta.0\"\n   checkout main\n   merge beta id: \"merge beta into main\"\n   branch changeset/main\n   checkout changeset/main\n   commit id: \"versioning main\"\n   checkout main\n   merge changeset/main id: \"merge changeset/main into main\" tag: \"v1.1.0\"\n```\n\n## Dev Deployment\n\n1. When you and your team want to develop new features or bug fixes, you may need to create a new branch from the `beta` branch. This new branch is called a `feature` branch.\n2. After you finish your code changes, you can merge the `feature` branch into the `dev` branch without opening a PR. GitHub Actions will automatically deploy your changes to the `dev` environment, allowing you to test your code without versioning.\n\n## Staging (Beta) Deployment\n\n1. If the `dev` environment is working correctly, you can open a PR from the `feature` branch to the `beta` branch. This will let reviewers know what's new in this PR.\n2. Don't forget to add a changeset file to describe the changes in your apps and packages. You can read more about [adding changeset](https://github.com/changesets/changesets/blob/main/docs/adding-a-changeset.md) here.\n\n   ![](./docs/assets/open-pr.png)\n   ![](./docs/assets/changeset-add.png)\n\n3. After the PR is approved and merged (using any merge strategy e.g. merge commit, squash commit), GitHub Actions will automatically create a new PR called **Version Packages (Beta)** that targets the `beta` branch. This PR will summarize the changes made to your apps and packages in this release, as illustrated below:\n\n   ![](./docs/assets/version-packages-beta.png)\n\n4. After the PR is merged, GitHub Actions will automatically publish your affected apps to the Container Registry, which in this case is GitHub Container Registry. Additionally, GitHub Actions will automatically create a GitOps PR called **Update GitOps** to bump the version of the image in K8s manifests, as illustrated below:\n\n   ![](./docs/assets/update-gitops-beta-1.png)\n   ![](./docs/assets/update-gitops-beta-2.png)\n\n   \u003e This step take advantage of [GitOps][10] to manage K8s manifests.\n\n   \u003e This step can take a significant amount of time to complete, as it involves building Docker images for your affected apps and pushing them to the Container Registry.\n\n## Production Deployment\n\n1. If you want to officially release your apps and packages to the production environment, you can open a PR from the `beta` branch to the `main` branch. At this step, you should ask the contributors if their changes work in the staging environment.\n2. After the PR is approved and merged (with any merge strategy), like staging deployment, GitHub Actions will open a PR called **Version Packages** to `main` branch. This PR will summarize the changes of your apps and packages in this release, like this.\n\n   ![](./docs/assets/version-packages-main.png)\n\n3. After the PR is merged, your affected apps will be published to the Container Registry with the bumped version, similar to the staging deployment. Additionally, an **Update GitOps** PR will also be opened to bump the version of the image in the K8s manifests.\n\n   ![](./docs/assets/update-gitops-main-1.png)\n\n4. Merge the **Update GitOps** PR to the `main` branch. This will automatically deploy your apps to the production environment.\n\n   ![](./docs/assets/update-gitops-main-2.png)\n\n\u003e Note: Every time the K8s manifests are updated, ArgoCD will automatically deploy your apps to the affected environment.\n\n# Sequence Diagram\n\nThe flow of development extended from [GitFlow][9] and the versioning workflow comes from [Changesets Release Action][6]. The following diagram shows the flow of development and versioning, as I explained above.\n\n## Scenario 1: Develop new features and deploy to dev environment\n\n```mermaid\nsequenceDiagram\n   Developer-\u003e\u003eGitHub: Checkout from 'beta' branch \u003cbr/\u003e called 'feature-1'\n   Developer-\u003e\u003eDeveloper: Develop new features\n   Developer-\u003e\u003eGitHub: Push code to 'dev' branch\n   GitHub-\u003e\u003eGitHub Action: Execute \u003cbr/\u003e'release-without-versioning' \u003cbr/\u003e workflow\n   GitHub Action -\u003e\u003e Container Registry: Publish affected apps \u003cbr/\u003e with 'git-sha' hash\n   GitHub Action --\u003e\u003e GitHub: Commit and push updated \u003cbr/\u003e k8s manifest files\n   GitHub -\u003e\u003e ArgoCD: Argocd is watched the k8s manifest. \u003cbr/\u003e It will automatically deploy affected apps to dev environment\n```\n\n\u003e After this step, you, who implemented the new features, should test your apps in the dev environment. If everything works properly, you can move to the next step.\n\n## Scenario 2: Deploy the new feature to staging environment\n\n```mermaid\n---\ntitle: Merge the feature PR to beta\n---\nsequenceDiagram\n   Developer-\u003e\u003eGitHub: Open PR from 'feature-1' to 'beta'\n   par Enter Pre-release mode\n      GitHub -\u003e\u003e GitHub Action: Execute 'pre-release' workflow\n      GitHub Action --\u003e\u003e GitHub: Enter changesets' pre mode \u003cbr/\u003e if the mode is not pre\n   and Changesets Bot\n      GitHub -\u003e\u003e Changesets Bot: Notify PR is opened to 'beta' branch\n      Changesets Bot --\u003e\u003e GitHub: Add a comment to the PR \u003cbr/\u003e to remind contributors to add a changeset file\n      Developer-\u003e\u003eGitHub: Add a changeset file\n      Changesets Bot --\u003e\u003e GitHub: Update the summary of changeset file\n   end\n   Developer-\u003e\u003eGitHub: Merge the PR\n   GitHub -\u003e\u003e GitHub Action: Execute 'release' workflow\n   GitHub Action --\u003e\u003e GitHub: Open a PR called 'Version Packages (Beta)' \u003cbr/\u003e to 'beta' branch\n```\n\n\u003e The **Version Packages (Beta)** is a PR created by [Changesets Release Action][6] in order to summarize the changes of your apps and packages in this pre-release.\n\n```mermaid\n---\ntitle: Release to the staging environment\n---\nsequenceDiagram\n   Developer-\u003e\u003eGitHub: Merge the release PR\n   par GitHub Releases\n      GitHub -\u003e\u003e GitHub Action: Execute 'release' workflow\n      GitHub Action --\u003e\u003e GitHub: Update 'GitHub Releases'\n      GitHub Action --\u003e\u003e Container Registry: Publish affected apps \u003cbr/\u003e with the bumped 'semver' version\n      GitHub Action --\u003e\u003e GitHub: Open a PR called 'Update GitOps'\n   and Sync 'beta' branch to 'main' branch\n      GitHub -\u003e\u003e GitHub Action: Execute 'sync-beta' workflow\n      GitHub Action --\u003e\u003e GitHub: Rebase 'beta' branch to 'main' branch\n   end\n   Developer -\u003e\u003e GitHub: Review and merge the 'Update GitOps' PR\n   Note over Developer, GitHub: 'Update GitOps' PR is created by \u003cbr/\u003e 'update-gitops' workflow in order to confirm \u003cbr/\u003e the changes of k8s manifest files\n   Note over Developer, GitHub: This PR may be in the another \u003cbr/\u003e repository.\n   GitHub -\u003e\u003e ArgoCD: Argocd is watched the k8s manifest. \u003cbr/\u003e It will automatically deploy affected apps to staging environment\n```\n\n\u003e After this step, you might see the new feature in the staging environment.\n\n## Scenario 3: Deploy the new feature to production environment\n\nAssuming that the new features on the staging environment work properly, you may want to officially release your apps and packages to the production environment.\n\nThis step is simpler than the pre-release step.\n\n```mermaid\n---\ntitle: Merge the beta to main\n---\nsequenceDiagram\n   Developer-\u003e\u003eGitHub: Open PR from 'beta' to 'main'\n   par Exit Pre-release mode\n      GitHub -\u003e\u003e GitHub Action: Execute 'pre-release' workflow\n      GitHub Action --\u003e\u003e GitHub: Exit changesets' pre mode \u003cbr/\u003e if the mode is not exit\n   end\n   Developer -\u003e\u003e Developer: Waiting for the relevant developers review\n   Developer-\u003e\u003eGitHub: Merge the PR\n   GitHub -\u003e\u003e GitHub Action: Execute 'release' workflow\n   GitHub Action --\u003e\u003e GitHub: Open a PR called 'Version Packages' \u003cbr/\u003e to 'beta' branch\n```\n\n```mermaid\n---\ntitle: Release to the production environment\n---\nsequenceDiagram\n   Developer-\u003e\u003eGitHub: Merge the release PR\n   par GitHub Releases\n      GitHub -\u003e\u003e GitHub Action: Execute 'release' workflow\n      GitHub Action --\u003e\u003e GitHub: Update 'GitHub Releases'\n      GitHub Action --\u003e\u003e Container Registry: Publish affected apps \u003cbr/\u003e with the bumped 'semver' version\n      GitHub Action --\u003e\u003e GitHub: Open a PR called 'Update GitOps'\n   and Sync 'beta' branch to 'main' branch\n      GitHub -\u003e\u003e GitHub Action: Execute 'sync-beta' workflow\n      GitHub Action --\u003e\u003e GitHub: Rebase 'beta' branch to 'main' branch\n   end\n   Developer -\u003e\u003e GitHub: Review and merge the 'Update GitOps' PR\n   Note over Developer, GitHub: 'Update GitOps' PR is created by \u003cbr/\u003e 'update-gitops' workflow in order to confirm \u003cbr/\u003e the changes of k8s manifest files\n   Note over Developer, GitHub: This PR may be in the another \u003cbr/\u003e repository.\n   GitHub -\u003e\u003e ArgoCD: Argocd is watched the k8s manifest. \u003cbr/\u003e It will automatically deploy affected apps to production environment\n```\n\n\u003e As a developer, you don't have to perform any manual deployment tasks to release the new feature to a specific environment. All you have to do is merge the relevant PRs.\n\n# How can I setup the CI/CD pipeline for my monorepo?\n\nThere are things you need to do if you already have your monorepo workspace set up, but for the most part, all you need to do is:\n\n1. Setup Changeset configuration\n2. Setup ArgoCD for your k8s cluster\n3. Copy/paste all workflows under [.github/workflow](./.github/workflows/) from this repository. (Make sure you understand what it's doing)\n4. Setup the secrets, `GH_TOKEN` ([GitHub PAT](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) with `repo` permission to let Action open the 'Update GitOps' PR)\n\n## Setup Changesets\n\n1. Install Changesets CLI in the root of the workspace:\n\n   ```bash\n   pnpm add -D -W @changesets/cli\n   ```\n\n2. Initialize Changesets:\n\n   ```bash\n   pnpm changeset init\n   ```\n\n   At this point, two files will be created:\n\n   ```\n   .changeset/config.json\n   .changeset/README.md\n   ```\n\n3. Configure the `config.json` file:\n\n   ```diff\n   {\n     \"$schema\": \"https://unpkg.com/@changesets/config@2.3.0/schema.json\",\n   - \"changelog\": \"@changesets/cli/changelog\",\n   + \"changelog\": [\"@changesets/changelog-github\", { \"repo\": \"ORGANIZATION_NAME/REPO_NAME\" }],\n     \"commit\": false,\n     \"fixed\": [],\n     \"linked\": [],\n     \"access\": \"restricted\",\n     \"baseBranch\": \"main\",\n     \"updateInternalDependencies\": \"patch\",\n     \"ignore\": []\n   }\n   ```\n\n   - `changelog` - This specifies the changelog generator used to generate the changelog for each package. In this case, we use the [GitHub changelog](https://github.com/changesets/changesets/tree/main/packages/changelog-github) generator.\n\n   \u003e Be sure to replace `ORGANIZATION_NAME` and `REPO_NAME` with your own GitHub organization and repository name.\n\n4. Add [Changesets bot](https://github.com/apps/changeset-bot) for your repository.\n5. Set up the GitHub Action workflow for releasing apps and packages. You can copy [my action YAML](./.github/workflows/release.yaml) here.\n6. For the apps that you want to build as Docker images, you need to add a `Dockerfile` to each of them. You can copy my Docker file here\n\n   - NextJS app - [Dockerfile](./apps/web/Dockerfile)\n   - NestJS app - [Dockerfile](./apps/api/Dockerfile)\n\n   \u003e Note the workflow will skip to build Docker images if there is no `Dockerfile` in the app. But it will still bump the version of the app.\n\n7. You're done! Now you're ready to use Changesets to release your apps and packages.\n\n## Setup ArgoCD to your cluster\n\nPlease following the [official documentation](https://argo-cd.readthedocs.io/en/stable/getting_started/) to setup ArgoCD for your k8s cluster.\n\nOr, follow the casual version of setup ArgoCD here\n\n1. [Setup ArgoCD Part 1][11]\n2. [Setup ArgoCD Part 2][12]\n3. [Setup ArgoCD Part 3][13]\n\n### Quick start\n\nInstall ArgoCD in `argocd` namespace\n\n```bash\nkubectl create namespace argocd\nkubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml\n```\n\nChange the `argocd-server` service type to `LoadBalancer`\n\n```bash\nkubectl patch svc argocd-server -n argocd -p '{\"spec\": {\"type\": \"LoadBalancer\"}}'\n```\n\nGet the default password of `admin` account, please wait for a while until the `argocd-initial-admin-secret` is created.\n\n```bash\necho $(kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath=\"{.data.password}\" | base64 -d)\n```\n\nSetup Application for ArgoCD\n\n```bash\nkubectl apply -f ./k8s/argo\n```\n\nIt'll create apps for every environment that defined in [apps](./k8s/apps).\n\nFinally, run the follwing command to port-forward the ArgoCD dashboard.\n\n```bash\nkubectl port-forward svc/argocd-server -n argocd 8080:443\n```\n\nThe dashboard will be available at [https://localhost:8080](https://localhost:8080)\n\n# FAQ\n\n1. What if I forgot to create a changeset file for my PR?\n\n   **Answer**:\n\n   You can create a changeset file for your change manually by running\n\n   ```bash\n   pnpm changeset\n   ```\n\n   Then, you can commit the changeset file and push it to the remote branch.\n\n2. What if I misspell the changeset file content?\n\n   **Answer**:\n\n   You can fix the changeset file's content any time you want before you merge the release PR. Make sure to review the changeset file every time.\n\n3. What if I want to 2-step pre-release e.g. `alpha` for the first pre-release and `beta` for the second pre-release?\n\n   **Answer**:\n\n   It's not possible for now. Since the Changeset does not support it right now.\n\n# Reference\n\nMany thanks to the authors and contributors of the following articles and projects, which provided valuable insights and inspiration for this article.\n\n- [What are Microservices][1]\n- [Monorepo.tools][2]\n- [Why you should use monorepo and why you shouldn't][3]\n- [Turborepo][4]\n- [Changesets][5]\n- [Changesets Action][6]\n- [GitHub Actions][7]\n- [ArgoCD][8]\n- [The GitOps Comparison: Pull and Push][9]\n- [GitOps Concept][10]\n- [Setup ArgoCD Part 1][11]\n- [Setup ArgoCD Part 2][12]\n- [Setup ArgoCD Part 3][13]\n\n[1]: https://microservices.io/ 'What are Microservices'\n[2]: https://monorepo.tools/ 'Monorepo.tools'\n[3]: https://lembergsolutions.com/blog/why-you-should-use-monorepo-and-why-you-shouldnt \"Why you should use monorepo and why you shouldn't\"\n[4]: https://turbo.build/ 'Turborepo'\n[5]: https://github.com/changesets/changesets 'Changesets'\n[6]: https://github.com/changesets/action 'Changesets Action'\n[7]: https://github.com/features/actions 'GitHub Actions'\n[8]: https://argo-cd.readthedocs.io/en/stable/ 'ArgoCD'\n[9]: https://faun.pub/gitops-comparison-pull-and-push-88fcbaadfe45 'The GitOps Comparison: Pull and Push'\n[9]: https://nvie.com/posts/a-successful-git-branching-model/ 'Git Flow'\n[10]: https://www.weave.works/technologies/gitops/ 'GitOps Concept'\n[11]: https://medium.com/thinc-org/%E0%B8%A1%E0%B8%B2%E0%B8%A5%E0%B8%AD%E0%B8%87-setup-gitops-%E0%B8%94%E0%B9%89%E0%B8%A7%E0%B8%A2-argocd-kustomize-%E0%B8%81%E0%B8%B1%E0%B8%99%E0%B9%80%E0%B8%96%E0%B8%AD%E0%B8%B0-part-1-8db644ccbd49 'Setup Argp CD Part 1'\n[12]: https://medium.com/thinc-org/%E0%B8%A1%E0%B8%B2%E0%B8%A5%E0%B8%AD%E0%B8%87-setup-gitops-%E0%B8%94%E0%B9%89%E0%B8%A7%E0%B8%A2-argocd-kustomize-%E0%B8%81%E0%B8%B1%E0%B8%99%E0%B9%80%E0%B8%96%E0%B8%AD%E0%B8%B0-part-2-e8016ec4cb07 'Setup Argp CD Part 2'\n[13]: https://medium.com/thinc-org/%E0%B8%A1%E0%B8%B2%E0%B8%A5%E0%B8%AD%E0%B8%87-setup-gitops-%E0%B8%94%E0%B9%89%E0%B8%A7%E0%B8%A2-argocd-kustomize-%E0%B8%81%E0%B8%B1%E0%B8%99%E0%B9%80%E0%B8%96%E0%B8%AD%E0%B8%B0-part-3-42c4fc714078 'Setup Argp CD Part 3'\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsaenyakorn%2Fmonorepo-versioning-gitops","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsaenyakorn%2Fmonorepo-versioning-gitops","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsaenyakorn%2Fmonorepo-versioning-gitops/lists"}