Answers: <p>You're basically describing GitOps. Here's how I've followed that for a containerized microservices build and deploy pipeline:</p>
  <ol>
  <li><p>Each service repo includes it's own Dockerfile, Kubernetes manifests, and anything else needed to locally build and test the project. The base image for the Dockerfile will likely be managed from another repo but built and hosted by the organization.</p>
  </li>
  <li><p>CI steps are mostly externalized to a set of common libraries or templates. So if there's a Jenkinsfile or equivalent, it sets a few variables and calls the common template to build and generate the artifacts.</p>
  </li>
  <li><p>Artifacts include a docker image, pushed to a registry, and also the deployment manifest (compose file, Kubernetes manifest, Helm templates), along with any other variables for those manifests. These deployment manifests/variables are pushed to a separate deployment repository that includes all of the microservices' manifest. There is only one deployment repo for all of the microservices in a single application stack, so this commit becomes a fan-in step. The push to this repository is scripted/automated during the CI of the microservice repo when a pull request is approved by enough trusted people to a protected branch. This provides the needed security checks.</p>
  </li>
  <li><p>The deployment repo commits triggers it's own pipelines that are effectively CD and following something close to a GitOps design. This could also be a GitOps tool monitoring the repo and applying the changes, but presently I've been sticking with a single CI tool that does both, simplifying the workflow and allowing some scripting to run on the deploy. That scripting for me loads the variables that were committed, applies additional variables (e.g. which environment is this being deployed to), renders the templates (currently a Helm umbrella chart), and deploys.</p>
  </li>
  <li><p>Deploys to other environments becomes a pull request between branches of the deploy repository. It could also be separate repositories to enforce security controls. Importantly, rendering the manifest should point to an immutable image tag or sha hash to ensure what was pushed to dev and tested there is the same as what's pushed to production. I include these image tags in a values file that is committed to the deploy repo.</p>
  </li>
  </ol>
  <p>One big advantage of this, multiple microservices that interact with each other are tested together and get deployed together as a unit, all services are fanning into a single deploy repo that contains their deployment manifests and what image tag to use. There's never the situation where service A gets a new feature, but it's buggy, service B gets built depending on that new feature, and service B gets released to production before service A (a common issue when each service is built and deployed in isolated pipelines). If A is blocking the deployment of the stack, then a pull request can be submitted to the deploy repo reverting the service A commit. Then if service B passes tests against an older service A, service B gets deployed to production.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-12-30T19:56:58.223Z
Answers: thank you @BMitch. That is what i'm looking for: GitOps
Answers: Murat Cabuk
Answers: CC BY-SA 4.0
Answers: 2020-12-30T23:56:23.663Z
Answers: This can also be called CI/CD. It does not need to have the GitOps buzz word :)
Answers: Jonas
Answers: CC BY-SA 4.0
Answers: 2020-12-31T00:41:31.107Z
Answers: The difference to me between GitOps and CD is where you keep the target state of the deployed environment. CD may have that state inside of Jenkins, or whatever you use to deploy it. GitOps considers Git to be the source of that current state, allowing any of the deployment tooling to be ephemeral. Also promotions to another environment are a commit or merge request, rather than a "next stage" action in the CD tooling.
Answers: BMitch
Answers: CC BY-SA 4.0
Answers: 2020-12-31T07:00:40.327Z
Answers: I agree with @BMitch, GitOps can be DevOps but DevOps cannot be GitOps. I think GitOps is a kind of deployment method/tecnic. Devops describes a definition in word, while gitops describes the way the work is done. For example, if DevOps is agile, GitOps is like Scrum. By the way I'm not the expert, I asked the question. I have been reading for 2 days about GitOps. I just write what i understand.
Answers: Murat Cabuk
Answers: CC BY-SA 4.0
Answers: 2020-12-30T19:26:39.023Z
Answers: 2020-12-30T19:26:39.023Z
Answers: BMitch
Body: <p>Is it appropriate to keep the DevOps resources in a different repo from the git repos where the project source codes are placed for the execution of DevOps processes?</p>
  <p>some benefits i expected</p>
  <ul>
  <li>Versioning files to a different repo such as Dockerfile, Jenkinsfile or Kubernetes deployment</li>
  <li>Ensuring the security of deployment processes</li>
  <li>Being able to manage the deployment processes of these projects since some projects consist of more than one repo</li>
  </ul>
  <p>I know the concepts of monorepo and multirepo, but what I say is a little different. What I mean is to abstract the repos of deployment files from the source code repos.</p>
  <p>Could this be a method of use? have you done something like this before? is this method useful? Does this method have a name or does it mean multirepo?</p>
  <p>I am waiting for your advice</p>
  <p>thanks everyone</p>
  
Tags: <deployment><continuous-delivery><methodology><process><monorepo>
Title: Separation of CI and CD processes
UserDisplayName: Murat Cabuk
ThreadText: # Separation of CI and CD processes
  
  (Asked by: username_0 on 2020-12-30)
  
  Is it appropriate to keep the DevOps resources in a different repo from the git repos where the project source codes are placed for the execution of DevOps processes?
  
  some benefits i expected
  
  * Versioning files to a different repo such as Dockerfile, Jenkinsfile or Kubernetes deployment
  * Ensuring the security of deployment processes
  * Being able to manage the deployment processes of these projects since some projects consist of more than one repo
  
  I know the concepts of monorepo and multirepo, but what I say is a little different. What I mean is to abstract the repos of deployment files from the source code repos.
  
  Could this be a method of use? have you done something like this before? is this method useful? Does this method have a name or does it mean multirepo?
  
  I am waiting for your advice
  
  thanks everyone
  
  **Tags:** deployment, continuous-delivery, methodology, process, monorepo
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-12-30. Score: 3 | Accepted answer
  
  You're basically describing GitOps. Here's how I've followed that for a containerized microservices build and deploy pipeline:
  
  1. Each service repo includes it's own Dockerfile, Kubernetes manifests, and anything else needed to locally build and test the project. The base image for the Dockerfile will likely be managed from another repo but built and hosted by the organization.
  2. CI steps are mostly externalized to a set of common libraries or templates. So if there's a Jenkinsfile or equivalent, it sets a few variables and calls the common template to build and generate the artifacts.
  3. Artifacts include a docker image, pushed to a registry, and also the deployment manifest (compose file, Kubernetes manifest, Helm templates), along with any other variables for those manifests. These deployment manifests/variables are pushed to a separate deployment repository that includes all of the microservices' manifest. There is only one deployment repo for all of the microservices in a single application stack, so this commit becomes a fan-in step. The push to this repository is scripted/automated during the CI of the microservice repo when a pull request is approved by enough trusted people to a protected branch. This provides the needed security checks.
  4. The deployment repo commits triggers it's own pipelines that are effectively CD and following something close to a GitOps design. This could also be a GitOps tool monitoring the repo and applying the changes, but presently I've been sticking with a single CI tool that does both, simplifying the workflow and allowing some scripting to run on the deploy. That scripting for me loads the variables that were committed, applies additional variables (e.g. which environment is this being deployed to), renders the templates (currently a Helm umbrella chart), and deploys.
  5. Deploys to other environments becomes a pull request between branches of the deploy repository. It could also be separate repositories to enforce security controls. Importantly, rendering the manifest should point to an immutable image tag or sha hash to ensure what was pushed to dev and tested there is the same as what's pushed to production. I include these image tags in a values file that is committed to the deploy repo.
  
  One big advantage of this, multiple microservices that interact with each other are tested together and get deployed together as a unit, all services are fanning into a single deploy repo that contains their deployment manifests and what image tag to use. There's never the situation where service A gets a new feature, but it's buggy, service B gets built depending on that new feature, and service B gets released to production before service A (a common issue when each service is built and deployed in isolated pipelines). If A is blocking the deployment of the stack, then a pull request can be submitted to the deploy repo reverting the service A commit. Then if service B passes tests against an older service A, service B gets deployed to production.
  
  > **Comments:**
  > **username_0**: thank you @username_1. That is what i'm looking for: GitOps  
  > **username_2**: This can also be called CI/CD. It does not need to have the GitOps buzz word :)  
  > **username_1**: The difference to me between GitOps and CD is where you keep the target state of the deployed environment. CD may have that state inside of Jenkins, or whatever you use to deploy it. GitOps considers Git to be the source of that current state, allowing any of the deployment tooling to be ephemeral. Also promotions to another environment are a commit or merge request, rather than a "next stage" action in the CD tooling.  
  > **username_0**: I agree with @username_1, GitOps can be DevOps but DevOps cannot be GitOps. I think GitOps is a kind of deployment method/tecnic. Devops describes a definition in word, while gitops describes the way the work is done. For example, if DevOps is agile, GitOps is like Scrum. By the way I'm not the expert, I asked the question. I have been reading for 2 days about GitOps. I just write what i understand.  
  
  ---
  
  