开源项目使用指南

说明

本指南是我在公司工作时听到一个浸淫开源社区多年的同事的一个分享衍生而来，我们公司内部有大量在使用的开源项目，包括但不限于K8s、Prometheus、Fission、Kubesphere、knative，Istio，其中的K8s和Prometheus，我们一般不会在它源码上进行修改（就这两个最早从CNCF毕业的项目来说，大部分人都没有能力写出比官方更好的代码。简单，是大师的责任；我等凡夫俗子，能做到清楚就很不容易了），最多也就是基于K8s operator做一些扩展，但是针对Fission或Kubesphere这种项目，我们还是有能力对其进行二次开发的（吐槽一下，Fission的官方代码其实写的就很一般）。
当初那位同事做分享旨在提供一个在公司内部使用外部开源项目的规范，一方面为了统一公司内部在使用开源项目时的工程实践，另一方面也希望能为想参与开源项目的同学提供一个贡献手册。

核心原则

1. 能不魔改就不要魔改
2. .魔改之前确认是否非得魔改，官方版本有没有暴露可以自定义设置的方式？
3. 没有自定义的方式，是你没找？还是没找到？还是没有？
4. 没有的话能不能你来提个 PR 让他支持自定义？

几种工程实践

只使用不魔改（推荐）

我们强烈建议大家不要魔改，而是直接使用社区版本。实际上对于成熟的开源项目来说你并没有能力对其进行魔改，魔改的后果只有更坏不会更好。

小范围魔改（跟踪社区版本）

开源社区的节奏往往慢于公司内部的节奏，如果我们在使用中发现了问题想要修复，提交 PR 等社区发版就太慢了。所以我们的建议是基于社区的 LTS 版本维护公司内部的版本分支。当我们发现问题时先在该分支上修复发布，后续再把该修复 PR 给社区。具体分支管理如下：

分支管理规范

当我们使用一个开源项目时，我们基于他最新的LTS 版本拉出我们公司内部的版本分支 1x-release-v1.x。
当使用过程中发现问题时：

1. 检查官方后续版本是否有修复该问题。
2. 如果己经发布了新版本修复了该问题，那么直接把新版本的分支合并到公司内部分支
3. 如果官方还没修复，我们在该分支上直接提交 MR 进行修复
4. 该分支同时向官方发起PR，请求并入官方的release 分支。
5. 如果主分支也存在该问题则也想主分支发起一个PR。(比如我的这PR:https://github.com/adap/flower/pull/2782)

我们建议遵循开源项目的构建逻辑，使用CI 来自动化构建制品（镜像）。
我们应该避免在本地手动构建，主要有以下两个原因：

1. 本地构建出来的制品不一定在服务端能运行
2. 手动构建的制品跟源码的版本之问没有强关联，并不能保证制品的版本号能对应到一个确定的代码版本上。这对手后期维护排查问题时会造成困扰：线上跑的这个版本到底对应的是不是我现在看的这份代码？

使用 GitHub（推荐）

开源项目往往使用 GitHub 的 Action 维护了完整的CI 流程。使用 GitHub 的CI能避免我们自己来维护 GitLab Cl 的成本。

使用 GitLab

如果使用 Gitlab，需要自行编写。gitlab-ciyml。

1. GitLab CI流水线配置文件.gitlab-ci.yml详解
2. 手把手教学编写gitlab-ci.yml文件以及应用（最简单易懂实践）

大范围魔改(不再跟踪社区版本)

随便玩