feat: add examples for dev to prod

content/docs/14.best-practices/1.from-dev-to-prod.md

@@ -14,15 +14,15 @@ Common patterns to deploy your flows from development to production environments
 One best practice with Kestra is to have one development instance where users can write their flow directly in UI. This instance can be seen as a "sandbox" where flows can be tested and executed without the fear to break critical business operations.
 
 We usually encourage two types of development environment:
-- installing Kestra on your local machine (usually with Docker Compose installation)
-- installing Kestra on a Kubernetes cluster accessible by users and separated from production matters.
+- installing Kestra on your local machine (usually with [Docker Compose installation](../02.installation/03.docker-compose.md))
+- installing Kestra on a [Kubernetes cluster](../02.installation/03.kubernetes.md) accessible by users and separated from production matters.
 
 ## Production Environment
 
 The production instance should be safeguarded. Especially as this environment supports critical operations and engages your responsibilities for end users.
 
 One common best practice here is to limit the access of the production environment. In this case, there two elements to consider:
-- Users access
+- User access
 - Flow deployments
 
 ### User Access
@@ -31,10 +31,15 @@ For Kestra Enterprise users, this is streamlined with [RBAC](../06.enterprise/rb
 
 For open-source users it's usually a good idea to have a restricted instance, meaning an instance only accessible by [CI/CD](../version-control-cicd/cicd/index.md) and administrators.
 
-
 ### Flows Deployment
 
-Kestra offers many strategies to deploy flows to an instance. Through the [UI directly](../08.ui/01.flows.md), [Git operations](../version-control-cicd/04.git.md), [Terraform](../13.terraform/index.md) or the [API](../api-reference/index.md) directly.
+Kestra offers many strategies to deploy flows to an instance:
+- [Through the UI](../08.ui/01.flows.md)
+- [Sync with Git](../version-control-cicd/04.git.md)
+- [CI/CD](../version-control-cicd/cicd/index.md)
+- [Terraform](../13.terraform/index.md)
+- [API](../api-reference/index.md).
+
 Choosing one way or the other depends of your preferences and your current deployment patterns.
 
 One recurring pattern is moving flows from the development to the production instance through [version control system](../version-control-cicd/04.git.md) and [CI/CD](../version-control-cicd/cicd/index.md).
@@ -51,3 +56,33 @@ The way CI/CD deploy flows to production instance can be addressed with the foll
 - Kestra CLI
 
 You can find more about CI/CD pattern with Kestra [here](../version-control-cicd/cicd/index.md).
+
+#### Git Example
+
+We can use the [`git.SyncFlows` task](/plugins/plugin-git/tasks/io.kestra.plugin.git.syncflows) combined with a [Trigger](../04.workflow-components/07.triggers/index.md) to automatically pull Flows from the `main` branch of the Git repository.
+
+This means Kestra will manage the process, reducing the number of systems needed to automate the dev to prod process. 
+
+You can use either a [Schedule Trigger](../04.workflow-components/07.triggers/01.schedule-trigger.md) to pull on a regular routine, e.g. nightly, or the [Webhook Trigger](../04.workflow-components/07.triggers/03.webhook-trigger.md) to pull when the `main` branch receives new commits. Check out this [dedicated guide](../15.how-to-guides/syncflows.md) on setting them up.
+
+If we combine this with the [`git.PushFlows` task](/plugins/plugin-git/tasks/io.kestra.plugin.git.pushflows), we can push our Flows to our repository from our local development environment, ensuring they are validated as Kestra will not let you save an invalid flow. 
+
+On top of that, we can automatically open a Pull Request with the [`create.Pulls` task](/plugins/github/tasks/io.kestra.plugin.github.pulls.create) to `main` to speed up the process of getting the Flows to production.
+
+::alert{type="info"}
+While we can be sure that our flows are valid, this will not check for logical errors. We'd recommend testing flows separately to check this before deploying to production.
+::
+
+#### CI/CD Example
+
+We can use CI/CD to automatically deploy our flows from our Git repository to our production instance of Kestra when they are merged to the `main` branch. 
+
+With GitHub, we can use the official [Deploy Action](../version-control-cicd/cicd/01.github-action.md#kestra-actions), which uses the Kestra Server CLI under the hood, to deploy when a Pull Request is merged to `main`.
+
+We can combine the **Deploy Action** with the [Validate Action](../version-control-cicd/cicd/01.github-action.md#kestra-actions), which runs a validate check on Flows using the Kestra Server CLI. 
+
+This means we can configure the Git Repository to require status checks to pass before a Pull Request can be merged - preventing any invalid flows from being deployed to production.
+
+::alert{type="info"}
+**Note:** If a flow is in an invalid format, the **Deploy Action** will fail.
+::