问题描述
你在GitHub上有多个代码仓库，希望构建、测试和部署它们。你选择了一个持续集成服务（例如Travis CI、AppVeyor或其他），并编写了一些用于构建、测试和部署的脚本。如果你的项目非常相似，比如都是使用Golang编写的，构建的结果始终是一个Docker镜像，部署始终是推送到Docker Hub，你不希望在所有仓库中重复这些脚本。你该如何避免重复？
解决方案
请注意以下操作可能涉及不同的工具和方法，根据实际情况选择适合你的方式。
方案1：提取共享部分为独立脚本或库
你可以将脚本中的共享部分提取出来，作为独立的脚本或库（根据你使用的脚本语言和个人喜好），并将其放在共享的位置（当然，需要有自己的代码仓库）。
- 首先，将脚本中的共享部分提取出来，并创建一个独立的脚本文件或库。
- 将这个独立的脚本文件或库放在一个共享的位置，可以是你的某个仓库中。
- 在代码仓库的脚本中，用从共享位置调用这些提取出来的脚本或库的方式替代原来的重复部分。
一些CI/CD工具可能能够直接从共享位置调用脚本，因此如果在某些代码仓库的脚本中没有特定部分，你可以完全从这些仓库中删除它们。
方案2：使用Git子模块
你可以考虑使用Git子模块来将共享脚本集成到你的代码仓库中。
- 创建一个包含你的构建、测试和部署脚本的共享仓库。
- 在你的代码仓库中添加一个Git子模块，指向共享仓库。
- 在你的代码仓库中，使用子模块中的脚本来代替重复的部分。
这样，你只需要维护共享仓库中的脚本，就能够在多个代码仓库中共享和使用这些脚本。
方案3：考虑使用构建工具
如果你觉得脚本的管理变得复杂，你还可以考虑使用一些构建工具来简化整个过程。以下是一些可能的构建工具：
Gradle： Gradle是一个强大的构建自动化工具，可以用于构建、测试和部署项目。你可以编写自定义的构建脚本，将共享部分提取为插件，然后在不同的代码仓库中引用这些插件。
Make： 如果你的脚本是基于Bash的，你可以考虑使用Make来管理构建过程。你可以创建一个Makefile，将共享部分定义为变量或目标，然后在不同的代码仓库中使用这些变量或目标。
方案4：使用自定义Docker镜像
如果你的构建脚本需要一些特定的工具或环境，你可以考虑使用自定义的Docker镜像来进行构建。
- 创建一个自定义的Docker镜像，其中包含了构建、测试和部署所需的工具和环境。
- 在代码仓库的构建脚本中，使用这个自定义的Docker镜像来运行构建过程。
这样，无论在哪个代码仓库中运行构建，都能够保证使用相同的工具和环境。
请注意，选择适合你项目和团队的方案时，要考虑到工具的复杂度、维护成本以及对团队成员的熟悉程度。
总结
通过提取共享部分为独立脚本或库、使用Git子模块、考虑使用构建工具或自定义Docker镜像，你可以避免在多个代码仓库中重复构建脚本，提高了代码的可维护性和复用性。根据你的项目需求和团队情况，选择适合的方案来优化你的构建、测试和部署过程。
提示：在实际操作中，请根据具体的工具和技术文档来进行配置和操作，确保脚本和配置的正确性。