update

src/前端视角下的 DevOps.md

@@ -12,9 +12,11 @@
 4. 自行将压缩包上传到服务器或者发给后端同事代劳。
 5. 将服务器上的压缩包解压到 WebRoot 目录下。
 
-这几乎是**最简单**的构建和部署需求了。但是作为程序员，这个流程操作几次后很快感到了厌烦。于是我开始学习 NodeJs 并编写了一段几十行的脚本来让计算机代我处理这些麻烦事，在确认脚本部署的程序正确运行的那一刻，我获得了巨大的成就感。后来才知道这件事情就是人们常说的 CI。
+这几乎是**最简单**的构建和部署需求了。但是作为程序员，这个流程操作几次后很快感到了厌烦。于是我开始学习 NodeJs 并编写了一段几十行的脚本来让计算机代我处理这些麻烦事，在确认脚本部署的程序正确运行的那一刻，我获得了巨大的成就感。
 
-扩展一点来说，CI 的出现是为了**自动化构建与部署的过程并使其可监控**。它有很多种实现方式, 可以是上文提到的一段简单的 NodeJs 脚本，可以使用 *Github Actions*，也可以使用 *Jenkins*。人们相信这个过程能够加速软件的开发和迭代效率，我对此深信不疑，因为一段脚本就为我节约了几分钟的发呆、学习、喝水时间，还不用担心因为操作失误带来的后果。对于
+后来我知道了这件事情就是人们常说的 CI。
+
+扩展一点来说，CI 的出现是为了**自动化构建与部署的过程并使其可监控**。它有很多种实现方式, 可以是上文提到的一段简单的 NodeJs 脚本，可以使用 *Github Actions*，也可以使用 *Jenkins*。人们相信这个过程能够加速软件的开发和迭代效率，我对此深信不疑，因为一段脚本就为我节约了几分钟的发呆、学习、喝水时间，还不用担心因为操作失误带来的后果。我相信对于规模更大更复杂的项目它带来的正面影响只会越来越多。
 
 ### CD 持续交付 / 持续部署
 
@@ -26,7 +28,9 @@
 
 ### CI / CD 不分家
 
-其实无论是 CI 还是 CD，其核心理念都在于「持续」二字，换种说法就是「自动化」。其实我一开始想要从文章结构上划清二者的界限，但目前看来收效甚微。网络上对于 CI / CD 的叙述也多是混为一谈，或许这就像我在文章开头对技术的理解一样，它们代表的思想本就是一个整体。
+实际工作中对 CI / CD 流程的讨论更多的是对实现方案**成本**的考量。例如我所在的项目组主要由后端主导，考虑到离线部署的情况、前端技术栈的多变以及运维成本最终决定在开发期执行构建，将构建产物一同提交到仓库，CI 过程只负责拉取文件构建镜像，而不是在 CI 过程中完成这些事情。这个方案并不优雅，但在多方面考虑后最终还是作出了决定。
+
+无论是 CI 还是 CD，其核心理念都在于「持续」二字，换种说法就是「自动化」。其实我一开始想要从文章结构上划清二者的界限，但目前看来收效甚微。网络上对于 CI / CD 的叙述也多是混为一谈，或许这就像我在文章开头对技术的理解一样，它们代表的思想本就是一个整体。
 
 写到这里我开始觉得，在前端这个位置上对「DevOps」的理解其实相当有限，只领悟到了皮毛。或者说是因为平台和项目的关系，没能有很多机会参与这些工作的规划和设计, 就很难进一步体会这些技术或者思想对工程的意义。