Loading...

CI/CD 方法论

Created2019-12-13|Updated2026-05-19

|Word Count:248|Reading Time:1mins|Post Views:

CI/CD 的重要性

Martin Fowler说过，“持续集成并不能消除Bug，而是让它们非常容易发现和改正。”

持续集成和持续交付作为敏捷开发的一种最佳实践，通过包括构建、部署、测试、发布流程的自动化，实现质量内建，让质量问题可以快速发现和消除，从而提升软件交付的质量和效率。

基本策略

分支模型是CICD落地的源头，研发过程各角色间的协作方式以及研发过程内代码版本的流转方式都取决于分支模型。

首先划分环境。

划分环境后设计分支，注重开发和发布两个场景。

根据分支设计流水线，验证应该发生在全流水线里。

一般的分支模型

一般的分支模型

参考文献：
《在阿里，我们如何管理代码分支？》
《What is Trunk-Based Development?》
《提升团队的微服务落地能力》

Author: magicliang

Link: https://magicliang.github.io/2019/12/13/CI-CD-%E6%96%B9%E6%B3%95%E8%AE%BA/

Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.

Related Articles

Convention over Configuration over Programming

什么是 Convention over Configuration over Programming 在软件工程中，有一条重要的设计哲学层级： Convention over Configuration over Programming 约定优于配置，配置优于编程。这条原则的核心思想是：能用约定解决的问题，就不要引入配置；能用配置解决的问题，就不要写代码。它反映了软件设计中对复杂度管理的追求——越是高层次的抽象，使用成本越低，出错概率也越小。三个层次的含义 Programming（编程）编程是最灵活但成本最高的方式。开发者需要编写具体的代码逻辑来实现功能。每一行代码都是潜在的 bug 来源，都需要测试、维护和 review。编程适合处理那些真正需要定制化逻辑的场景。 Configuration（配置）配置是介于约定和编程之间的中间层。通过外部化的配置文件（如 XML、YAML、properties 等），开发者可以在不修改代码的情况下改变程序行为。配置降低了修改成本，但引入了配置管理的复杂度——配置项越多，理解和维护系统的难度就越大。 Convention（约定） ...

上下文换入换出：下一代 scaling

上一篇说裸模型像抽卡，因为它把概率输出直接暴露给用户。抽卡感解释的是一次任务里的波动；上下文问题解释的是长程任务为什么会累、会乱、会跑偏。 LLM 和人都有一个共同约束：它们都在上下文里工作。区别在于，模型的上下文 refill 是读写问题，人的上下文 refill 是注意力问题。机器可以把一段摘要重新塞进 message array，人却要重新把目标、材料、约束和下一步动作装回工作记忆。这个过程有磨损。人也有 context window 把 LLM 说成统计模型是对的，但这种说法容易遮住它和人的相似工作形态。人从长期通识积累到领域学习，再到职业训练和反馈，很像预训练、继续预训练和后训练的分层。拥有推理能力以后，人也不是在真空中推理，而是在一个被任务材料填充出来的上下文里推理。上下文质量决定注意力预算能不能被调动。APA 对 multitasking 的综述把任务切换带来的时间成本叫 switching costs。换到工程语境里，context switching 的问题不是“同时做两件事”这么简单，而是每次切换都要重新加载一组任务状态：目标是什么，做到哪里，哪些约束不...

第 1 章欢迎进入软件构建的世界第 2 章用隐喻来更充分地理解软件开发第 3 章三思而后行：前期准备第 4 章关键的“构建决策” 第 5 章软件构建中的设计第 6 章可以工作的类第 7 章高质量的子程序第 8 章防御式编程第 9 章伪代码编程过程第 10 章使用变量的一般事项第 11 章变量名的力量第 12 章基本数据类型第 13 章不常见的数据类型第 14 章组织直线型代码第 15 章使用条件语句第 16 章控制循环第 17 章不常见的控制结构第 18 章表驱动法第 19 章一般控制问题第 20 章软件质量概述第 21 章协同构建第 22 章开发者测试第 23 章调试第 24 章重构第 25 章代码调整策略第 26 章代码调整技术第 27 章程序规模对构建的影响第 28 章管理构建第 29 章集成第 30 章编程工具第 31 章布局与风格第 32 章自说明代码第 33 章个人性格第 34 章软件工艺的话题第 35 章何处有更多的信息

飞马模型来自 IBM 的 FSDM 模型飞马模型可以覆盖银行、证券和保险业务场景，更加容易实现“全局最优”的金融信息互通、集成标准的建立。飞马模型包括9类主题：产品、合约、条件、参与者、账户、事件、渠道、资源项、位置。与FSDM的9大概念（参与者、合约、条件、产品、地点/位置、分类、业务方向、事件、资源项）相比，飞马模型少了分类和业务方向，增加了账户和渠道两个主题，更加贴合金融业务特点。账户的概念来源于会计核算中的会计账户。银行账户是客户在银行开立的存款账户、贷款账户、往来账户的总称。银行业务就是在账户体系基础上为个人和对公客户提供各种金融服务。账户体系定义所有的操作均以交易的形式发生，也就是信息模型中的事件。渠道是银行为客户提供金融产品和服务的场所。渠道的作用在于触达客户、传递产品和服务、达成交易。对于传统金融机构，同时拥有线下渠道和线上渠道。而对于互联网金融来说，完全是线上渠道。这也决定了互联网金融的业务模式与传统金融机构相比存在较大的差异，渠道对于互联网金融来说意义更大。互联网渠道不仅能够完成触达客户、传递产品和服务、达成交易的基本作用，而且其所带来的全新优质...

Harness Engineering：长程 Agent 的工程化底座

微信公众号文章《Harness Engineering：让AI Agent长程运行的秘密武器》抓住了一个很重要的行业拐点：Agent 讨论正在从“模型有多强”转向“系统怎么让模型可靠工作”。这个判断是对的，但如果只把 Harness Engineering 理解成“给 Agent 做记忆和交接班”，还是太窄。更准确的定义是：Harness Engineering 是围绕模型构建一套可执行的工作环境、状态系统、工具边界、验证机制和反馈循环，让 Agent 能跨越单个上下文窗口，持续推进真实任务，并在失败时留下可恢复的证据。这不是 Prompt Engineering 的升级版，也不是 Context Engineering 的别名。Prompt 解决一次请求怎么说，Context 解决一次请求里放什么，Harness 解决的是任务生命周期怎么被系统托住。一、为什么 2026 年突然轮到 Harness OpenAI 在 2026 年 2 月发布的 Harness Engineering 文章里披露了一个内部实验：团队从空 Git 仓库开始，用 Codex 构建并发布一个内部...

AI 不会吞掉软件，只会吞掉入口

“AI 会吞掉所有软件”这个说法很有传播力，但技术上不够准确。更可能发生的事情是：软件本体继续存在，软件入口被 AI 重写。计算器、数据库、编译器、PDF 库、浏览器、CAD、CI、权限系统、ERP 不太会因为 LLM 出现而消失。它们处理的是确定性状态、格式、权限、计算和副作用。LLM 不适合直接替代这些系统，却很适合成为它们上方的意图入口。确定性系统不会消失裸模型不是确定性程序。它可以写出计算器代码，但不应该代替计算器执行财务计算；它可以解释 PDF 结构，但不应该靠想象修改 PDF 二进制；它可以生成 SQL，但实际执行、回滚、审计和加锁的仍然是数据库。这不是模型能力不够强时的临时现象，而是范式边界。真实软件世界需要可复现、可审计、可回滚、可授权。神经网络输出可以生成候选方案，却很难成为这些确定性承诺本身。 Claude Code Skills 的 PDF 示例很能说明问题。一个 PDF skill 会把操作流程写进 SKILL.md，再借助 pypdf、pdfplumber、脚本和参考资料处理文件。实际改 PDF 的不是模型“懂了 PDF”，而是模型调度了确定...