特别鸣谢：感谢ChatGPT和New Bing，真是写作之利器。
版本控制，也称为源码控制、代码管理，是跟踪和管理软件代码的工作实践。随着信息化、数字化技术的发展，源代码逐渐成为企业的核心数据资产，在企业中有着非常重要的地位。所以如何管理好代码这个数据资产，是每一个企业都需要考虑和解决的问题。而作为数字化时代的先行者，大部分互联网和科技型企业已经完成或者部分完成了这项工作，并借助敏捷开发、DevOps等方法论和工具实现了代码的规范、可靠管理，以及高效高质量的产品交付。
在产业数字化转型，企业DevOps转型的大趋势下，近些年有不少传统嵌入式开发的企业开始参与进来。嵌入式与互联网、科技公司有着不同的技术栈、开发模式和交付方式，对他们来说，并不能发扬拿来主义精神，将“前辈”的经验直接复用。需要结合实际情况走出一条不一样的路，这里首当其冲要解决的就是代码的可靠管理、高效协同以及高质量交付问题。
GitLab CI依靠其一体化、轻量化、声明式、开箱即用的特性，在开发者群体中的使用率越来越高，在国内企业中仅次于Jenkins排在第二位。GitLab流水线有4种不同的类型，分别是：有向无环图流水线、多项目流水线、父子流水线、合并列车。但仅靠这些流水线类型的名称和官方描述很难理解它们的意义和用途，这也导致GitLab CI在开发者群体中使用的深度不够。在与用户沟通和自己实践的过程中，我也梳理了这些流水线类型的功能，并以简洁明了的方式重新“定义”了这些流水线类型，希望能给GitLab CI的初学者一些帮助和参考。
DAG Pipelines 全称是Directed Acyclic Graph Pipelines，即有向无环图流水线，官方的定义和介绍如下：
有向无环图 可以在 CI/CD 流水线的上下文中，用于在作业之间建立关系，以便以最快的方式执行，无论阶段如何设置。
例如，您可能拥有作为主要项目的一部分而构建的特定工具或单独的网站。使用 DAG，您可以指定这些作业之间的关系，系统会尽快执行作业，而不是等待每个阶段完成。
WIKI百科对于UI测试的解释是：
图形用户界面测试是测试产品的图形用户界面（GUI）以确保其符合其规格的过程。这通常是通过使用各种测试用例来完成的。
按照UI测试的目的，可分为逻辑测试和视觉测试：
WIKI百科对于单元测试的解释是：
单元测试又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
熟悉敏捷开发，尤其是XP极限编程的小伙伴对单元测试应该不陌生，XP是TDD（测试驱动开发），这里面的测试就是指单元测试。
WIKI百科对于性能测试的解释是：
性能测试用于评估和确定系统在特定工作量下的响应和稳定方面的性能。可以用于调查、测量、验证系统的其他质量属性，例如可扩展性，可靠性和资源使用情况。
性能测试按照测试目的不同，可分成不同类型，常见的类型有：
WIKI百科对于接口测试的解释是：
接口测试是软件测试的一种，它包括两种测试类型：狭义上指的是直接针对应用程序接口（下面使用缩写API指代，其中文简称为接口）的功能进行的测试；广义上指集成测试中，通过调用API测试整体的功能完成度、可靠性、安全性与性能等指标。
接口测试根据其测试目的不同，来决定测试人员和测试方法：
WIKI百科对于软件测试的定义是：
在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
软件测试是伴随着计算机和软件开发的发展而发展的，有记录的信息可以追溯到1958年的美国第一个载人航天计划——水星计划，在该计划中首次描述了软件测试团队及其工作内容。从软件测试出现到现在，大致可分为五个阶段：
调试为导向：20世纪50年代初期，当时还没有明确测试（Testing）和调试（Debugging）之间的区别，所以也没有测试或测试人员的概念。开发人员主要是以调试为主，验证程序是否符合预期。
证明为导向：1957年，Charles L Baker在对Dan McCracken的著作《Digital Computer Programming》进行评审时，提出了测试的概念，并对调试和测试进行了区分：
1957年到1978年，软件测试的主要目标是确保软件满足功能需求，也就是我们常说的“做了正确的事情”。
破坏为导向：1979年，Glenford J. Myers在《The Art of Software Testing》一书中阐述了一个成功的测试用例是检测到尚未发现的错误。说明测试不仅要证明软件做了正确的事情，也要保证它没做不该做的事情。这也使得软件测试和软件开发独立开来，测试需要更为专业的人员进行，毕竟开发人员在心理上总是不愿意给自己开发的软件找错。
评估为导向：1983年，出现了大名鼎鼎的V&V（验证和确认）理论，也就是现在测试人员熟悉的V模型，软件测试被应用在整个软件生命周期（SDLC）中。 这段时期软件测试的重点是检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别，以及通过测试来评估和衡量软件质量。
预防为导向：1988年至2000年提出了一种新的测试思路。代码被分为可测试的和不可测试的，可测试的代码比难以测试的代码更少，所以测试的重点应该是在代码级别防止缺陷。20世纪的最后十年出现了探索性测试，测试人员探索并深入了解软件，试图找到更多的错误。2000年前后也出现了测试驱动开发（TDD）和行为驱动开发（BDD）等新概念的兴起。而2004以后，伴随敏捷开发模式的推广，自动化测试工具和持续集成等技术的应用，都体现出人们不再满足于传统的、后置的仅保证功能正确的软件测试，而是希望尽早的、高效的、全面的发现和识别问题。
企业内部一般都会有多个业务、应用系统，为建立统一的用户管理、身份配给和身份认证体系，实现一个账号登录所有系统，需要建立一套统一身份认证服务平台。
统一身份认证服务平台一般包含以下几个部分：
而单点登录(SingleSignOn，SSO)，不光可以实现一个账号登录所有系统，它通过用户的一次性登录认证，就可以访问多个应用。SSO一般会被包含在认证管理功能里。
GitLab支持多种身份认证和授权方式，可以与企业的统一身份认证服务平台集成。包括对接AD/LDAP实现统一账号，对接SAML、CAS、Auth0、OAuth2等实现SSO。GitLab对于AD/LDAP、SAML、CAS、Auth0的对接提供了详细的文档。而对接Generic OAuth2的文档较粗放，网络上也没有太多参考资料，所以整理了一篇GitLab对接OAuth2的实践文章。
使用GitLab CICD，在部署方面，主要有两种方式：
部署到K8S集群
Push模式：流水线通过kubectl执行命令部署，这需要把K8S的权限给流水线，存在安全风险
Pull模式：使用GitLab Agent for Kubernetes或ArgoCD，通过GitOps的方式“监听”GitLab的变化，触发部署
部署到服务器
目前仍有不少企业因为行业性质或者场景所限，没有使用K8S等云原生技术，还在采用传统的服务器方式进行部署。一般使用ssh、scp、rsync等命令部署到服务器。GitLab也提供了基于SSH keys的部署。详见：Using SSH keys with GitLab CI/CD | GitLab
需要说明的是，如果是使用专用的编译机进行编译构建，然后部署到指定的服务器，只需要实现编译机和部署服务器的免密SSH登陆即可，相对简单。但如果使用容器进行编译构建，然后部署到服务器，就需要按照上面文档中提到的，配合GitLab CI/CD环境变量，将SSH_PRIVATE_KEY等变量存储到GitLab Project、Group或Instance中，实现复用。且可以通过GitLab CI/CD环境变量的Mask设置，掩藏这些变量在CICD日志中的显示。详见：GitLab CI/CD variables | GitLab
但遗憾的是Mask功能目前是有限制的，对于SSH_PRIVATE_KEY这种多行的变量无法直接使用Mask功能。这样开发人员就可以在.gitlab-cti.yml文件的脚本中执行echo $SSH_PRIVATE_KEY，在流水线的日志中输出SSH Keys，存在密钥泄露风险。
The value of the variable must:
- Be a single line.
- Be 8 characters or longer, consisting only of:
- Characters from the Base64 alphabet (RFC4648).
- The
@and:characters (In GitLab 12.2 and later).- The
.character (In GitLab 12.10 and later).- The
~character (In GitLab 13.12 and later).- Not match the name of an existing predefined or custom CI/CD variable.
这个问题在GitLab的Issue上挂了有一年多 ，看样子短时间没法解决。有没有其他方式Mask SSH_PRIVATE_KEY？于是开始了各种折腾。
WARNING：本文含有强烈的刺激性气味，请勿在进食期间阅读。如感到血压上升、眩晕、呼吸急促，请立即停止阅读。
祖传代码（Legacy Code），就字面意思而言，就是无数的前任程序猿留给你的最后遗产。这些代码几乎没有可维护性，缺少注释、命名不规范、依赖错综复杂，你根本读不懂它，但神奇的是它们都能跑起来。不要试图修改它们，因为要么就无从下手，要么一改就出大问题。每家公司都会有那么些“历史遗留问题”。亚马逊的工程师亲切的形容他们的祖传代码为“屎山”：“每次你想修正一个bug，你的工作就是爬到屎山的正中心去”。
一家企业里，偶尔一两座屎山无伤大雅，毕竟每家企业都有很长的故事。但如果“你看那一座座山，一座座山川，一座座山川相连”，这种情况就很危险了。山路十八弯，难以持续的为企业快速增长提供高效支撑。企业发展的越快，屎山的债务积累就越多，形成恶性循环，最终企业员工只能望山兴叹，下山逃难去了。如何解决屎山问题？如何形成一个正向的发展循环？如何打造一个研发流程的最佳实践？如何加强质量内建？那我们就要先爬到屎山的正中心去一探究竟，明知山有屎，偏向屎山行。