CICD 的目标是代码的快速、可靠上线运行，它应当以 DevOps 理念落地为核心，将好的 Coding 规范、运维策略融合入 CICD 系统。
简单将其归为五化（如果包含智能化，就是六化啦，但这是个长期的、不断演进的过程，不可能一蹴而就，是技术+数据）：
- 标准化：这是 CICD 的灵魂，它是软件工程最佳实践的落地，也是企业内部规范的落地，是具有企业特色、团队风格的软件产品。很多公司开发 CICD 系统的目的也是统一发布模式，简化发布流程。有两点需要说明的是，其一，标准并非是对的，但是它是必须要遵守的，由于标准制定者的认知或是历史因素，有些标准可能并非正确，如有的团队认为 CI 和 CD 是一个事情，主张二者捆绑在一起，但是实际上，我们更倾向于二者分离。其二，标准也非一成不变的，而是持续优化改进，它需要与时俱进，适用技术需求、业务需求以及开发人员诉求。
- 可配置化：CICD 系统要提供一些配置接口，便于对一些启动参数、部署模板进行修改。但是，虽然我们支持配置，但并不主张配置，我们更倾向于约定：约定大于配置，减少不必要配置，如果配置项可以通过约定固化下来，我们不建议配置。很多软件都有丰富的配置菜单，虽然面面俱到，却又让人烦不胜烦，配置可以让功能丰富，也让操作更复杂。因而，近些年，流行“约定大于配置”，比如变量名是驼峰好呢？还是 snake 好呢？这些都是形式而已，无需同时支持，统一规范即可。
- 自动化：自动化最好理解，通过系统替代人工，减少人工误差，节约人力成本，让人发挥其真正的价值，而非重复的劳动。
- 可视化：让用户更好的感知 CICD 的过程，也方便其排障。可视化并非是简单的报表、图线，它应当是人机交互的接口，通过系统 UI，让开发了解进程状态，实时合规的操作进程，提供 Web 终端，让开发排障更简单。
- 简便化：“让系统操作更简单”，说说很容易，开发之前的简便性设计，会成为上线后的用户抱怨，很多情况下，设计者并不了解用户，尤其是 CICD 这样的内部系统，没有 PM，需求全靠猜，UI 随便写，其结果就是用户全抱怨。如何做到简便化？我觉得，最简单的就是走近用户，吸收意见，不断重构。运维开发有一个很坏的观念，“反正内部使用，能用就行”，这种观念很害人，这样既会影响自己的品味，也会影响自己的 KPI。
四、开发过程中的一些问题
从产品设计到目前的 2.3 版本，这一路走来，确实遇到了许多问题，有技术问题，也有观念问题，今天摘取几个分享：
1. 交互问题
CICD 系统并非孤立的系统，它需要与一些第三方系统协同，有时候是 API 的互通、有时候是数据的同步，因此，队友给不给力，也是很重要的。第三方系统的架构设计也会影响 CICD 的设计。比如，我们的用户权限设计就分为两套，一套是系统权限管理，另一套就是从第三方系统同步而来，因为从设计上就很难达成一致。人生是门妥协的艺术，软件也是如此，要学会向历史妥协、向第三方妥协、向企业文化妥协。
2. 收与放的度量
多系统协同，很容易出现这样的问题，一个功能在 A 系统中实现，和在 B 系统中实现，效果都一样，那么如何抉择呢？比如，我们在设计 Pipeline 管理时，就在这遇到问题，有人主张将 Pipeline 做成 SDK，也有的主张将 Pipeline 做成可配置的组件，我选择了后者（因为我就是主张者），因为如果将 Pipeline 做在 CICD 里，虽然以组件拼装的方式会复杂些，但是可以将一些标准固化在代码里，而如果依赖于第三方提供的 SDK，那么这些标准能否很好的遵守，就很难判断啦。
更复杂的是，有些时候，收与放并非技术层面的度量，而是利益的瓜葛，这往往是影响最终结果的主要因素。见过有些团队为了争夺某一应用话语权，打的是妻离子散、分崩离析。遇到这类的事情怎么办？我的观点，客观审慎、长远打算、合理建议、尊重决定。无论作何决定，都有领导层的考虑，无非是会走些弯路，但是如果不走，谁也不知道是曲是直。
真正的流水线需要具备的 15 个特性：
- 版本控制
- 最优的分支策略
- 代码静态扫描
- 80%以上的单元测试覆盖率
- 漏洞（Vulnerability）扫描
- 开源工具扫描
- 制品（Artifact）版本控制
- 环境自动创建
- 不可变服务器（Immutable Server ）
- 集成测试
- 性能测试
- 每次提交都触发：构建、部署和自动化测试
- 自动化变更请求
- 零停机发布
- 功能开关
