00 PAC是什么
大家最早都听过IaC，也就是Infrastructure as Code。由于虚拟化和云计算的快速发展，使得以代码形式管理基础设施成为可能，它也给IT管理方法带来了新的机会，最终激发了DevOps的产生。
PaC也就是Pipeline as code出现的时间相对较晚，它是指将构建和部署的流水线使用代码形式进行管理。在此之前，流水线一般使用UI形式进行创建和编辑，保存在持续集成系统的数据库中。
那么PaC相比传统的UI形式流水线有哪些优势和劣势呢？
01 PAC的优势
- 利于团队内部协作。由于将保存Pipeline编排的YAML/JSON放在了代码库中，新同学可以从这个YAML中学习到如何构建和部署工程，要修改流水线编排也需要经过团队的代码检视；
- 利于和外部开源协同。协同者在fork这个代码库后，也能很快了解工程的流水线交付方式并且run起来；
- 权限和操作收敛。流水线通过代码形式保存在代码库中，权限继承了代码库，管理起来很轻快方便；
- 版本控制。由于代码库本身就有版本，便于回滚；
- 审计跟踪。所有针对流水线的修改都有commit记录，审计方便；
02 PAC的劣势
- 使用YAML配置有较高的学习成本。相比UI形式流水线所见即所得，Pipeline as code需要学习一种DSL(Domain Specific Language)，使用门槛较高；
- 数百上千行YAML难以理解。当YAML中代码行变多之后，要理解这个YAML在干什么就变得很困难了，修改流水线变得容易出错，升级流水线变得困难；
- 权限依赖代码库。对于一些复杂的项目，可能存在一些角色可以查看流水线，但是不能查看代码库，此时就难以满足了；
03 PAC代表产品
最有代表性的产品包括Github action、travis ci、circle ci等，同时像Gitlab、jenkins也已经支持Pipeline as code了。
以下是Tencent/bk-ci的github action界面，主要是在提交PR时进行pre-merge看能否编译成功。
04 一些思考
其实Pipeline as code可以分为2个重要的部分，一是使用pac进行编辑，二是将pipeline存储到代码库中。
使用pac进行编辑要求有一种简洁的DSL来表达pipeline，例如Github action就有自己的YAML语法。当大家都熟悉了这一种DSL后，就可以直接通过编写代码YAML或JSON来编辑pipeline了。随着pipeline越来越复杂，编码越来越容易出错，因此需要引入YAML格式检校、UI辅助等。
将pipeline储存到代码库中与使用pac进行编辑不一定强关联，两者是可以解耦的。如果pipeline以YAML或其他格式储存到了代码库，那么它的编辑权限将会继承代码库，所有的版本也会留在代码库的commit记录中。当一个人fork一个代码库后，他可以从dockerfile、helm charts了解到工程微服务部署方式，也可以从.github/workflows的yaml中了解到pipeline怎么串联构建、代码检查、单元测试和部署。
总而言之，Pipeline as code是一种不错的实践，但优点和缺点也很明显。它不一定适合所有项目。如果你觉得它的优点十分吸引你，而它的缺点在你的项目中无关紧要，不妨大胆去尝试吧。
更多内容欢迎关注我的微信公众号>>
