Answers: <p>This is a similar problem I've been facing. And we're not the only ones it seems. GitLab just added a very interesting feature in their recent 10.5 release where you can pull external files into the pipeline.</p>
  <p>In their blog post, they had this to say:</p>
  <blockquote>
  <p>For many of our largest customers, the DevOps team is responsible for providing CI/CD pipelines to a large number of development teams throughout the organization. Previously, this was a painful process to manage. There wasn’t a scalable way to distribute reusable pipeline configuration which meant code needed to be manually copied between multiple .gitlab-ci.yml files in multiple projects. This was a labor-intensive and error-prone process. Additionally, it didn't provide adequate controls to ensure testing and deployment is consistently enforced for each repo.</p>
  <p>Starting with 10.5, you can now include external files in CI/CD pipeline definition. Included files can be either local (contained in the same repo) or remote (accessible via HTTP/HTTPS). Including local files allows a large and complex .gitlab-ci.yml to be broken up in to modular chunks that are easier to maintain.</p>
  </blockquote>
  <p><a href="https://about.gitlab.com/2018/02/22/gitlab-10-5-released/#include-external-files-in-cicd-pipeline-definition" rel="noreferrer">https://about.gitlab.com/2018/02/22/gitlab-10-5-released/#include-external-files-in-cicd-pipeline-definition</a></p>
  <p>This is probably the best way to approach it from a OOP perspective as well: modularize certain aspects of your builds and include it in downstream code.</p>
  <p>My peers working at another company do a similar approach with their Jenkins builds. They've essentially build on a 'makefile' for their builds that is based on templates and evaluates certain variables set in the Jenkins UI. Based on those variables, the code will then fetch (curl or git) 'module' files from a central 'builds' repository. It then uses all the modules to compile a single pipeline bash script and runs it.</p>
  <p>This allows central changes to be done to a single file, that all the builds inherit.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-02T16:36:10.970Z
Answers: 2018-03-02T16:36:10.970Z
Answers: 2020-06-18T08:28:10.803Z
Answers: BoomShadow
Body: <p>At the moment there are more than 100 different deployment files. The majority of the config is identical, but there are some differences and therefore every docker image has its own deployment template. If a change has to be made to one of the deployment.yamls, most of the time this has to be copied to other files as well and that is a little bit tedious. How to apply Don't Repeat Yourself (DRY) while constructing k8s files without creating spaghetti?</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-03-01T22:55:55.937Z
Comments: Generate them with a configuration management tool? (or whatever templating system)
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-03-01T23:06:13.270Z
Comments: You mean for example ansible? I found [this](http://docs.ansible.com/ansible/latest/kubernetes_module.html), but it does not seem to be able to deploy containers.
Comments: 030
Tags: <kubernetes>
Title: How to apply DRY to k8s files?
UserDisplayName: 030
ThreadText: # How to apply DRY to k8s files?
  
  (Asked by: username_0 on 2018-03-01)
  
  At the moment there are more than 100 different deployment files. The majority of the config is identical, but there are some differences and therefore every docker image has its own deployment template. If a change has to be made to one of the deployment.yamls, most of the time this has to be copied to other files as well and that is a little bit tedious. How to apply Don't Repeat Yourself (DRY) while constructing k8s files without creating spaghetti?
  
  **Tags:** kubernetes
  
  > **Comments:**
  > **username_1**: Generate them with a configuration management tool? (or whatever templating system)  
  > **username_0**: You mean for example ansible? I found [this](http://docs.ansible.com/ansible/latest/kubernetes_module.html), but it does not seem to be able to deploy containers.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-03-02. Score: 5 | Accepted answer
  
  This is a similar problem I've been facing. And we're not the only ones it seems. GitLab just added a very interesting feature in their recent 10.5 release where you can pull external files into the pipeline.
  
  In their blog post, they had this to say:
  
  > For many of our largest customers, the DevOps team is responsible for providing CI/CD pipelines to a large number of development teams throughout the organization. Previously, this was a painful process to manage. There wasn’t a scalable way to distribute reusable pipeline configuration which meant code needed to be manually copied between multiple .gitlab-ci.yml files in multiple projects. This was a labor-intensive and error-prone process. Additionally, it didn't provide adequate controls to ensure testing and deployment is consistently enforced for each repo.
  >
  > Starting with 10.5, you can now include external files in CI/CD pipeline definition. Included files can be either local (contained in the same repo) or remote (accessible via HTTP/HTTPS). Including local files allows a large and complex .gitlab-ci.yml to be broken up in to modular chunks that are easier to maintain.
  
  <https://about.gitlab.com/2018/02/22/gitlab-10-5-released/#include-external-files-in-cicd-pipeline-definition>
  
  This is probably the best way to approach it from a OOP perspective as well: modularize certain aspects of your builds and include it in downstream code.
  
  My peers working at another company do a similar approach with their Jenkins builds. They've essentially build on a 'makefile' for their builds that is based on templates and evaluates certain variables set in the Jenkins UI. Based on those variables, the code will then fetch (curl or git) 'module' files from a central 'builds' repository. It then uses all the modules to compile a single pipeline bash script and runs it.
  
  This allows central changes to be done to a single file, that all the builds inherit.
  
  
  ---
  
  