这篇来聊 CI (Continuous integration) 的导入须知， 什麽是 CI ，中文常见是翻"持续整合"。 (也有人是 CI / CD 持续整合/持续交付 并称， 我以下都只说 CI，但涵盖是 CI/CD。) 虽然是一个常见而且通用的概念， 我个人觉得因为名字不太好懂，很多人还是一知半解。 DevOps 很大一部分的工作会跟这题有关， 这个词的发展就我接触的顺序早 DevOps 不少。 这十年来有些词汇的发展先後不一， 都是根据当时的市场跟分工需求，定义上有些混乱。 -------- CI 最基本的概念，至少包含， 把一个专案从 source code ，到他真的上服务， 这一段 flow 中间的自动化。 换言之， checkout 自动，build 自动， local(nightly) release 自动，deploy 自动。 很多人对这题可能认知的只有build专案的服务。 虽然最早 CI 其实是搭配 test ，因为持续发布持续测试， 所以在每个版本可以迅速找到"假设"被破坏的地方回馈。 不过国内撰写测试风气不发达， 真的做到测试能涵盖到确保安全的地方，就我所见不多。 但即使如此，build 仍然是过版失误中，相当常见的主因， 诸如 build 错版本，丢错版本，丢错地方，下错环境参数等等。 CI 在 build 自动化的优点在於， 只要设定好一个已经变化不大的 build process 。 剩下的要出错的机率很低， 因为机器基本上都是 step by step process。 一般来说，做好 CI 有几个好处： 1. build 版不用倚赖特定工程师的脑内思维，把工程师的中断减少(不会被叫去过版或buil 2. 设定即文件，而且是活的文件 3. 为测试整合打好基础 4. 减少测试环境的过版负担 5. 能够提供水平角色(pm/qa) 自动存取最新 build 的资料， 包括 web / app / 各类执行档。 有些专案甚至是每天对外发 nightly version ， 就是个典型 CI 流程的特徵。 ---------- 目前圈内常见的 CI 手段， 最基本的大概是定期跑排程，一些 batchjob 勉勉强强就算数了。 其他常见工具包括 jenkins (前身为 hudson)，Travis CI ， travis CI 的优点是跟 github 无缝整合。 可能还有一些其他的，我自己是比较习惯用 jenkins 。 也不是他特别好还是怎样，从早期就一直用到现在懒得改， 另外是步骤都可以 shell base ， 换言之你能用指令做到的就能用他做，我是用的很习惯。 另外 azure devop 也有提供 pipeline & release， 可以做对应的事情，不过 azure 封装的比较多， 用起来我自己是觉得跟 jenkins 风格大异其趣。 -------- 导入时的第一个问题，build 的环境处理： 当你装好 jenkins ，他就是个 web server ， 然後你可以使用该台 server 上的环境进行建置。 也可以建多台 slave ，到别台机器上去建置。 (比方说某些有平台相依的，ex. mac vs windows) 建置时有些工具需要分开安装， 如 build android 需要 android sdk ， build .net framework 需要 msbuild。 dotnet core 需要 dotnet core runtime 。 除了像 azure pipeline 有提供线上能 build 的机器(要收钱)， 其他大部分都是得自己搞定。 另外要留意一件事情是为了隔离性， CI 的执行使用者通常不是我们进入操作的高权限帐号， 一开始的各类设定，档案权限处理，通常会花一点力气。 --------- 第二个常碰到的问题，在於不熟悉指令建置的 input output 。 比方说微软体系的 msbuild ，多数人可能用过 vs 的发布工具， 但对 msbuild 怎麽用不熟。 其实能用 vs 做到的都能用 msbuild 做到， 但有时需要钻过茫茫复杂设定海。 另外就是 build 出来的 package 在哪，有时候需要找， 有些专案设定甚至会影响 build 的结果。 要留意跟团队沟通有变化时要更新对应的 build 设定。 像是 android 有些人会改 gradle 设定档，加入档名的变化， 这个设定如果 build 那边没考虑到就会事倍功半。 --------- 第三个常碰到的问题，在於权限管理的模型设定， 有些地方是采取集中建置的策略， 有些地方是让工程师各自建置的策略。 其中特别需要的部分， 是把测试环境跟建置环境的权限分开。 另外设定档的保存，不要让没有权限的人， 存取到超过他权限的设定档也是重要课题之一。 ----------- 第四题跟第三题有点重叠，在於各类环境设定的处理。 目前主流有几派，一个是设定在 os 的环境变数。 (台湾我是非常少看到有专案这样做) 一个是独立保管设定档， 但保管在哪这点目前无标准化，就我看到大家都是各做各的。 如找个 private blob (or s3) 放之类的， 也有人是交给 ansible 之类的发布作业接手。 ----------- 常见的问题还包括讨厌的跨专案间的相依问题， 比方说某专案需要某建置工具的 A 版本， 另一个专案需要某建置工具的 B 版本。 有时候会需要费心去处理版本的 bin 指定跟环境安装。 ---------- 最後因为每次建置，大多数预设的情况， 我们会保留 workspaces 跟 output file 。 所以如果专案 build 出来的东西不幸比较肥， 那可能会常常把伺服器的空间塞爆， 这里的空间管理就会是问题。 常见做法是直接接到外部的 file service 做保存。 ---------- CI 有时候大家会开始设定 trigger ，可能 A 专案建置完之後，要跟着整套建完上测试之类的。 当单一建置时间太常，团队人又多时，有可能会导致建置服务的塞车。 我们可能也要留意设定上，设定是不是适当的， 举例，每次都需要 clone 整个专案吗？ 还是只需要取最新版就好。 每次都要重装相依性套件吗？(ex. maven , npm , nuget ) 能不能 local cache ，或是内部有个 cache service， 有些设定在 build 时，会需要稍微调校来加快效能。 总之，很多人觉得自动化建置，等於再久也没关系， 实务经验来说，我觉得还是得追求建置速度， 快速反应，快速前进。 还有一些相对比较不多人关心的问题， build fail 的处理要怎麽安排，这些就是有空再说了。 我个人会建议，有机会的话，多了解一些发布流程如何自动化， dotnet 工程师看看 msbuild 跟 dotnet(core) . android 玩一玩 ./gradlew assembleRelease signapk 怎麽指令化操作 ios 玩一玩 xcode 对自己手边专案的掌握跟理解都会比较上升。 有时候也可以帮自己省下不少时间， 省下多一点的时间，不管是要混要认真， 还是要在周末上网写废文，都会比较有时间。(笑) ----- Sent from JPTT on my Google Pixel 3 XL. -- I have a dream, it's silly but beautiful. --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.167.67.203 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1598230146.A.8A1.html 已修正，谢啦 ※ 编辑: TonyQ (114.136.135.6 台湾), 08/24/2020 09:28:58 ※ 编辑: TonyQ (114.136.135.6 台湾), 08/24/2020 09:29:19 ※ 编辑: TonyQ (114.136.135.6 台湾), 08/24/2020 09:29:34 是说几个朋友在FB说, 觉得 CI 跟 build 还是有差, 欸 我觉得原则上同意, 因为 build 只是基础的一环. 至於有了自动 build 是不是就能达到持续整合的精神, 比方说虽然有 build server 但还是每个月 build 一次. 那样就不能说有持续整合的精神. 这我同意啦 只是说论述总有远近, 要讲到持续整合这个架构, 能进入的人又少太多了. XDDD (啊是说你们自己来回啊. = =) ※ 编辑: TonyQ (210.61.209.201 台湾), 08/24/2020 14:15:18 战是写文的原动力 XD ※ 编辑: TonyQ (118.167.72.246 台湾), 08/27/2020 05:38:45