1. 概述​

本文介绍软件成本评估的一些相关标准和评估方法，内容包括：

• 软件功能规模度量和成本费用测算相关的现行国家标准。
• 软件功能规模度量的国际标准，五种度量方法：分别为 IFPUG、MARK Ⅱ、COSMIC、NESMA 和 FiSMA 方法。
• 当前 IFPUG 方法和 NESMA 方法是目前最主要的标准，优先考虑采用。

2. 国家标准（功能规模度量和成本费用测算）​

2023年3月17日，中华人民共和国国家标准公告（2023年第1号）发布，公告中发布了一系列国家标准，其中包含三项软件功能规模测量国家标准，标准由全国信息技术标准化技术委员会归口，全国信息技术标准化技术委员会软件与系统工程分会执行 ，主管部门为国家标准化管理委员会。

三项软件功能规模测量国家标准如下：

其它现行的相关国家标准（截止：2024年6月）：

3. 国际标准（功能规模度量）​

功能规模度量相关国际标准（截止：2024年6月）：

4. 五种功能规模度量方法​

在度量方法的发展演进中，有五种方法被 ISO 国际标准组织接受成为了 ISO 国际标准，分别是：

• IFPUG
• Mark-II
• NESMA
• FiSMA
• COSMIC

1979年10月，Allan Albrecht 博士首次提出了一种评估软件系统功能的技术方法。他的技术方法被采用，成为国际标准。1987 年，IFPUG 成立，负责管理和发展 Albrecht 的技术。在接下来的几年中，又启发了其他几种度量方法出现。它们（按出现顺序）是：Mark-II（1988）、NESMA FPA（1990）、FISMA（199x）和 COSMIC（1998）。

五种度量方法的发展历史

5. 该选取哪种方法标准​

对于上述五种不同的规模度量标准，它们的功能点类型、应用范围、可操作性和应用现状等方面都有各自不同的特点，但就其应用的广泛程度来看，IFPUG 标准和 NESMA 标准仍然是目前最主要的标准。国际组织中超过 90% 的数据采用 IFPUG/NESMA 方法，国内的行业数据则 100% 采用 IFPUG/NESMA 方法；同时，由于 IFPUG 方法和 NESMA 方法被认为是等效的（即 IFPUG 方法所度量的1个功能点基本等同于 NESMA 方法所度量的一个功能点），近几年各行业在应用软件成本度量行业及国家标准时，主要采用 IFPUG/NESMA 方法，各地政府在制订地方标准时，也主要参考 IFPUG/NESMA 方法。

6.相关网站：​

[1] 全国标准信息公共服务平台
[2] 国家标准全文公开系统
[3] 中国质量标准出版传媒有限公司(中国标准出版社)
[4] 中国质量标准出版传媒有限公司(中国标准出版社) 主办中国标网
[5] 北京软件造价评估技术创新联盟
[6] 中国软件行业协会软件造价分会
[7] ISO 国际标准化组织
[8] IFPUG 国际功能点用户组
[9] nesma
[10] COSMIC

7.其它参考​

[1] 40 Years of Function Points: Past, Present, Future
[2] 五种ISO功能点方法介绍
[3] COSMIC 度量手册中文版
[4] COSMIC-FFP and IFPUG 4.1 Similarities and Similarities and Differences

1. 概述​

本文介绍在梳理客户业务流程时，使用 BPMN 来进行流程建模绘图。 并提供一些可以供学习的资源链接。

2. 使用 BPMN 表达业务流程的好处​

• 简单易懂一目了然。
• 具有丰富的符号，可以精确的表示从简单到复杂的每个用例。
• 为需求人员提供了以图形符号理解和表达客户业务流程的能力，并可以以标准方式向其它相关方传达这些信息。
• 它是工作流建模的标准。是众多商业或开源工作流引擎底层采用的技术。

3. BPMN 简介​

BPMN(Business Process Modeling and Notation 业务流程建模和表示法) ，是业务流程建模的全球标准。BPMN 图表允许项目中不同的相关方可视化的表达业务流程。项目中的业务客户、需求分析师、开发人员、业务经理，每个人都使用相同的表达语言来描述业务流程，从而更容易使业务需求沟通的更加准确和高效。

BPMN 最初由 Business Process Management Initiative (BPMI) 开发，是一种用于记录业务流程的精确图形符号。它通过直观地描述完成特定流程所需的业务活动和信息流的顺序来解决流程规范的歧义。

自 2005 年以来，BPMN一直由对象管理组 Object Management Group（OMG）维护。BPMN 2.0 是 OMG 关于流程改进三个标准之一，另外两个是：CMMN（Case Management Model Notation 案例管理模型符号)和 DMN（Decision Model and Notation 决策模型符号）。

当前 OMG 的 BPMN2.0.1 规范已作为国际标准 ISO/IEC 19510:2013 Information technology — Object Management Group Business Process Model and Notation 发布。

4. 可视化编辑器​

• Camunda Modeler - Open Source Desktop Modeler（推荐使用）

  • https://camunda.com/download-camunda-7/

• BPMN Viewer and Editor（开源项目）

  • https://bpmn.io/
  • https://github.com/bpmn-io

• draw.io（开源项目）

  • https://www.drawio.com/
  • https://github.com/jgraph/drawio

• BPMN Editor（Visual Studio code 扩展插件）

  • BPMN Editor

• Red Hat Business Automation Bundle（Visual Studio code 扩展插件）

  • Red Hat Business Automation Bundle

参见：安装 Red Hat Process Automation Manager VS Code 扩展捆绑包

5. 入门指南​

5.1 BPMN 提供以下三种图类型​

• Collaboration diagrams 协作图显示了使用多个池的两个或多个进程之间的交互。协作图侧重于每个池执行的工作，反过来，每个池可以在彼此之间传递消息。
• Choreography diagrams 编排图显示了两个或多个参与者之间的交互。编排图可以包含在协作中，添加任务和序列，以确定参与者如何更充分地交互。
• Conversation diagrams 会话图是协作图的简化版本。它们显示了业务流程中的一组相关消息交换。

5.2 入门指南​

这是一篇简单的入门指南，介绍了基本符号的使用。

• BPMN Tutorial: Quick-Start Guide to Business Process Model and Notation

5.3 一个简单的人员招聘需求发布的示例​

6. 接下来​

本文的内容非常简略，只是一个简单的介绍，下面的几个链接资源包括了上面所提到的内容，可参考。

• BPMN 官网
• BPMN 2.0 规范
• BPMN 2.0 示例
• BPMN Quick Guide
• BPMN 2.0 Symbol Reference
• BPMN Tutorial: Quick-Start Guide to Business Process Model and Notation
• ISO/IEC 19510:2013 Information technology — Object Management Group Business Process Model and Notation
• Cheatsheets
  • [PDF]file1
  • [PDF]file2
• [PDF]BPMN Guide Quick Start by Bizgig BPM
• BPMN Tool Matrix

7. 其它一些额外的资料​

• ORG DMN
• camunda
  • Camunda bpmn
  • DMN Tutorial
  • BPMN 2.0 Implementation Reference
  • CMMN 1.1 Implementation Reference
  • DMN 1.3 Reference

1. 系统与软件工程标准简述​

系统与软件工程领域国外有一系列指导标准，随着近年来我国信息技术的发展，国家也推出了中国自己的标准，这些标准不是强制性的，而是推荐和建议指导性质的标准。这些标准种类繁多，覆盖了系统与软件工程领域的各个过程，其中有一些标准是比较重要的，这里仅列出国家标准（GB）和国家军用标准（GJB）中最主要的几个。

2. 国家标准（GB）​

（1）基础标准

（2）文档化标准

（3）生存周期管理标准

（4）质量与测试标准

3. 国家军用标准（GJB）​

主要标准

• GJB 5000B-2021 军用软件能力成熟度模型
• GJB 2786A-2009 军用软件开发通用要求
• GJB 438C-2021 军用软件文档编制通用要求
• GJB 5612-2006 军队计算机信息系统安全保密防护要求及检测评估方法
• GJB 9001C-2017 质量管理体系标准
• GJB/Z 141-2004 军用软件测试指南
• GJB 439A-2013 军用软件质量保证通用要求
• GJB 2115A-2013 军用软件研制项目管理要求
• GJB 8000-2013 军用软件研制能力等级要求
• GJB/Z 161-2012 军用软件可靠性评估
• GJB/Z 102A-2012 军用软件安全性设计指南
• GJB/Z 172-2015 军用软件风险管理指南
• GJB 5234-2004 军用软件验证和确认

1.前言​

12 要素应用程序 (12-Factor App) 是由 Heroku 的开发人员定义的用于构建云原生应用程序的一组原则。

然而，它诞生已超过十年，云技术自最初创建以来一直在发展。为了使应用程序能够真正利用现代云基础设施和工具，并在云中蓬勃发展，Kevin Hoffman 修订了最初的12个要素原则，并增加了三项，该书由 O’Reilly 出版社出版。书名是：Beyond the Twelve-Factor App

下面简要介绍这 15 个设计原则。

2. 15个架构设计原则​

2.1 One codebase, one application 一个应用，一个代码仓库​

一个应用一个代码仓库，这里的应用也指微服务，一个微服务通常是具有一定业务边界的功能服务，当我们的软件系统有大量微服务组件时，每个微服务应该有自己的代码仓库。如果多个微服务有共享模块，那么这个共享模块也应该有独立的代码仓库，并使用依赖管理策略去加载它。

2.2 API first API优先​

设计 API 时遵循 API 设计规范 OpenAPI v3规范

2.3 Dependency management 依赖管理​

在 Java 项目中，依赖管理的两个流行的工具是 Maven 和 Gradle。工具有助于简化依赖管理的复杂性，开发人员能够声明他们的依赖关系，然后让工具负责实际确保这些依赖关系得到满足。

2.4 Design, build, release, and run 设计，构建，发布，运行​

这条准则的目标是要最大化的提升发布速度，同时通过自动测试和自动部署来让我们对发布抱有信心。

2.5 Configuration, credentials, and code 配置，证书，和代码​

配置指会随着部署环境发生变化的值，包括：

• 后端服务的 URLs 和其他信息，比如 web service 和 SMTP 服务
• 连接到数据库的必要信息
• 调用第三方服务的证书
• 可能需要放到 XMl 或者 YMAL 配置文件的其他属性

配置并不包括程序本身的内部信息，也就是说，如果某一个值在所有的部署环境都是一样的，它就不是配置。

证书是极其敏感的与代码无关的信息，通常来说，程序员会把证书从程序源代码里面提取出来放到属性文件里面，但是这样做并没有解决问题。 因为配置文件本身仍然是代码仓库的一部分，这意味着证书与程序一起发布，这本身就打破了这条规则。

一个最简单的检验证书和配置是否合理的方式，就是假设现在需要把源代码 push 到 GitHub 上面， 如果外面的人需要访问你的代码，你是否把你依赖的服务的敏感信息给暴露出去了呢？不是你的组织内部的人是否看到了内部后端服务的 URLs，证书或者其他敏感的信息呢？

如果能够在不暴露任何敏感信息的情况下去开源你的代码，那么你可能在隔离你的代码、配置、证书方面做的很好了。

外化配置的方式是可以使用一个配置中心，比如开源的 Spring Cloud Configuration Server，或者其他的配置服务产品。

2.6 Logs 日志​

将日志视为事件流，Logs 应该被当作一种事件流，也就是说， logs 是程序内部发出来的时间有序的事件序列。一个真正云原生的应用从来不关心如何路由和存储它的输出流。

应该将日志的聚合，处理和存储视为一项非功能性要求，该要求不是由应用程序满足，而是由云提供商或平台上面的其他工具套件来满足。可以使用ELK技术栈（ElasticSearch，Logstash 和 Kibana），Splunk，Sumologic 等工具或任何其他工具来捕获和分析日志。

2.7 Disposability 易处理​

通过快速启动和优雅关机最大限度地提高稳健性。 如果一个应用程序不能快速的重启和停止，那么它就不能快速的扩展，部署，发布和恢复。要在构建应用的时候想到这一点。

如果应用程序正在一个高负载的场景下，就需要快速的启动更多的实例去处理这个负载，但是慢启动会阻碍通过扩展去处理较高的负载。如果应用程序不能快速和优雅的关闭，会失去失败场景下快速恢复的能力，不能快速关闭的能力同样会有耗尽资源的风险。

许多应用程序会在启动过程中有一些耗时较长的动作，例如获取数据缓存起来或者加载一些依赖项。需要单独处理这种动作。例如，可以将缓存外部化为后端服务，以便应用程序可以快速启动和关闭，而无需执行启动前加载动作。

2.8 Backing services 支持服务​

将支持服务视为附加资源，将外部组件（如数据库、电子邮件服务器、消息代理和系统人员可以提供和维护的独立服务）视为附加资源。将资源视为支持服务可以提高软件开发生命周期中的灵活性和效率。

这意味着应用程序没有一行代码会与某个特定的服务耦合到一起，可能会有一个用来发送邮件的后端服务，需要通过 SMTP 连接到邮件服务。但是邮件服务的实现细节不会影响到应用，同时应用也不会依赖于某个固定位置的 SMTP 服务器。

2.9 Environment parity 同等环境​

尽可能的保持开发，预发布，线上环境相同，这一点很重要，以便可以确保所有潜在的错误/故障都可以在开发和测试中识别出来，而不是在应用程序投入生产时暴漏出来。

TestContainers 工具使我们能够确保测试环境也尽可能接近生产环境。

2.10 Administrative processes 管理进程​

后台管理任务当作一次性进程运行。

不鼓励将一次性管理或管理任务放在微服务中。包括迁移数据库和运行一次性脚本来进行清理。这些应该作为一次性进程运行，它们可以作为 kubernetes 任务运行。 这样，服务可以专注于业务逻辑。

管理进程示例包括：

• 数据迁移
• 运行定时脚本，比如一个凌晨的批量任务
• 运行一次性的自定义的程序

2.11 Port binding 端口绑定​

云原生应用通过端口绑定的方式暴露服务。网络可以通过端口号而不是域名来识别服务或应用程序。其原因是，域名和相关的IP地址可以通过手动操作和自动服务发现机制即时分配。因此，将它们用作参考点是不可靠的。根据端口号将服务或应用程序暴露给网络更可靠，也更容易管理。至少，由于网络私有端口号分配和另一个进程公开使用相同端口号之间的冲突而导致的潜在问题可以通过端口转发来避免。

2.12 Stateless processes 无状态进程​

云原生应用程序应该是一个单一的无状态进程。所有持久状态都必须在应用程序外部，由后端服务提供。因此，无状态不是说不存在状态，而是说状态不能在应用程序中维护。

例如，一个提供用户管理功能的微服务是无状态的，因此所有用户的列表都在后端服务（例如 MongoDB 数据库）中维护。

2.13. Concurrency 并发​

向一个大块的单体应用增加CPU核数，增加内存和其他的资源（虚拟的或者物理的），这种做法被称之为垂直扩展，这种做法不适用于云原生应用。

一个更加理想的扩展方式是水平扩展，相比较于把一个本来就很大的服务进程弄的越来越大，可以创建多个进程，然后在这些进程中分配负载。

大多数云提供商已经完善了这一功能，可以配置规则，根据负载或系统中可用的其他运行时遥测动态扩展应用程序实例的数量。

kubernetes 为我们提供了完善的设施来解决水平扩展的问题。

2.14 Telemetry 遥测​

遥测的字面定义是使用特殊设备对某物进行特定测量，然后使用无线通讯将这些测量传输到其它地方。遥测点到源头的测量是需要通过远程，远距离，无实物连接的方式来完成的。

这里特指监控和测量我们的云原生应用。当需要监控应用的时候，这里通常会有多种不同类型的数据：

• 定期健康检查
• 请求审核
• 业务级别事件
• 性能指标和系统日志

在规划监控策略时，要考虑清楚到底需要聚合多少信息、信息传入的速率以及要存储多少信息。如果应用程序从1个实例动态扩展到100个实例，那么也会导致日志流量增加百倍。

开源行业标准 OpenTelemeter 是在应用程序中实现有效分布式跟踪的工具，OpenTelemetry 是各类 API、SDK 和工具形成的集合。可用于插桩、生成、采集和导出遥测数据（链路、指标和日志），帮助你分析软件的性能和行为。

2.15 Authentication and authorization 认证和授权​

在理想情况下，所有云原生应用程序都将使用 RBAC（基于角色的访问控制）保护其所有 API 。对应用程序资源的每个请求都应该知道是谁发出请求，以及该使用者所属的角色。这些角色决定调用客户端是否有足够的权限让应用程序接受请求。

有了 OAuth2、OpenID Connect 等工具，各种SSO服务器和标准，以及各种语言特定的身份验证和授权库，安全性应该从一开始就融入到应用程序的开发中，而不应该是在应用程序在生产环境中运行一段时间之后再加上的一个功能。

3. 参考​

[1] 云原生计算基金会（CNCF）
[2] 12 要素应用程序 (12-Factor App)
[3] Kevin Hoffman. Beyond the Twelve-Factor App. O’Reilly
[4] Beyond the Twelve-Factor App 中文版
[5] An illustrated guide to 12 Factor Apps
[6] Creating cloud-native applications: 12-factor applications
[7] Beyond the 12 factors: 15-factor cloud-native Java applications
[8] OpenAPI 英文官网
[9] OpenAPI 中文官网
[10] kubernetes
[11] TestContainers
[12] OpenTelemeter
[13] OAuth 2.0
[14] Master OAuth 2.0 from this guide with modern use cases and real-world examples

1. 简介​

作为软件开发工作的一部分对数据库进行建模是在项目的早期，但随着开发的进展，数据库模型会存在修改。在项目后期也可能由于客户提出的变更导致数据库模型的修改。许多看似不起眼的改动都可能给系统带来严重的后果。

我们希望有一种方法可以将数据库模型的修改和部署更新尽可能的平滑，把对系统可能的影响降到最低，并且即使发生问题也可以快速定位和修复，不造成毁灭的影响。

2. 数据库部署问题​

软件开发中数据库的更改和部署有下面常见的一些问题。

• 数据库生产部署可能由团队外部的DBA完成，他们不熟悉我们开发的应用程序，也可能不了解数据库结构
• 手动部署容易出现人为错误
• 手动部署通常需要等到发版窗口时间
• 可能会向其他人提供不正确的脚本，从而导致部署错误的代码
• 数据库的多个副本存在于不同的开发人员计算机上，因此很难确定要使用和部署的正确版本

3.数据库源代码控制示例​

假如我们有一个名为 dept 的表。这是创建它的脚本：

CREATE TABLE dept (
  id NUMBER,
  name VARCHAR(100)
);

我们会将此文件保存为 “dept.sql” 文件，将其添加到我们的存储库中，提交并将其推送到远程代码存储库。

如果想对数据库进行更改怎么办，例如我们增加一个 status 字段？这引出了一个我们该决定如何管理数据库代码的问题。

有两个方案，是基于状态的版本控制和基于迁移的版本控制。

• 方案一 基于状态

修改原有的 detp.sql 脚本。每当需要对表进行更改（例如添加状态列）时，它就会得到更新。

CREATE TABLE dept (
	id NUMBER,
    name VARCHAR(100),
	status VARCHAR(20)
);

• 方案二 基于迁移

创建另一个新的脚本 customer_add_status.sql。一个脚本创建客户表，另一个脚本添加状态列。

ALTER TABLE dept ADD COLUMN status VARCHAR(20);

4. 基于状态 VS 基于迁移​

基于状态和基于迁移是数据库版本控制的两种方法。

基于状态：当存储反映数据库当前状态的数据库代码时，称为基于状态的版本控制。可以使用版本控制中的代码来创建数据库，脚本表示当前数据库定义是什么。

基于迁移：当存储反映为到达数据库当前状态而采取的步骤的数据库代码时，称为基于迁移的版本控制。版本控制中的脚本反映用于创建对象的原始脚本，以及后续所有变化的过程脚本。

基于状态的好处是

• 被认为更简单，因为只有一组脚本（例如，每个对象一个脚本，或一些其他划分）。
• 对象的定义在一个地方，所以任何人都可以打开它看看它应该是什么样子。
• 版本控制提交历史将告诉我们更改了什么、何时以及谁更改了它们。

基于迁移的好处是

• 数据库可以建立到某一时间点的状态，这有助于在有多个环境和分支的团队中使用
• 所有更改都在单独的脚本中，因此知道什么正在更改以及何时更改
• 由于脚本更小，部署可能更容易

数据库代码应该反映数据库的当前状态，还是应该反映为达到数据库的当前状态而采取的步骤呢？采用哪种方法需要与团队一起来讨论利弊。

通常的建议是使用基于迁移的部署，好处可能更多一些。这带来的另一个问题是可能会有大量过程脚本，当有大量过程脚本或者部署执行脚本带来大量的时间消耗的时候，我们可以用重新确定数据库脚本基线的方式来处理。

5. 重新确定数据库脚本的基线​

重新基线化数据库部署脚本涉及将所有数据库部署脚本组合成一组反映数据库当前状态的脚本。这可以减少对同一对象上的数据库所做的更改数量，从而减少部署时间。

例如，假设在一年的时间里，对表进行了几次更改：

1. 从原始脚本创建表
2. 添加新列
3. 添加索引
4. 更改列的数据类型
5. 再加三列
6. 删除列
7. 将表拆分为两个表

在所有这些脚本之后，很难判断表的样子。可以重新设置脚本基线，而不是为每个部署运行所有这些脚本。这意味着您可以创建一个脚本来创建当前状态的数据库，而不是运行所有这些迁移。

6. Liquibase & Flyway​

使用比较广泛的数据库迁移工具有 Liquibase 和 Flyway，这两种工具都可以实现基于迁移的数据库部署工作。有开源的免费版本和付费商业版本。

• Flyway https://flywaydb.org
• Liquibase https://www.liquibase.org

7. 一些建议原则​

下面是一些建议的指导原则。

• 脚本一旦进入代码库，就不能更改。

一个脚本被添加到版本控制后，如果想对数据库进行更改，无论多小，都要编写一个新脚本。不要更改旧脚本。

• 使用脚本而不是手动更改数据库。

所有更改都应使用相同的过程完成：编写新的脚本文件并在部署过程中获取它。这有助于避免数据库中的意外错误更改并确保一致性。

• 确保每个开发人员都有自己的本地数据库，而不是共享的开发数据库。

请确保团队每个人都有自己的本地开发数据库。

• 避免脚本中的独占锁。

编写的脚本可能会自动或手动在它们正在处理的表上放置独占锁。尽量避免在部署脚本中这样做，因为这会减慢部署过程。不过，这取决于使用的是哪个数据库供应商，因为某些数据库在某些情况下具有表级锁，而另一些则没有。

8. 如何实现上述方案​

在团队中实现这一点可能需要一定的时间。技术方面可能需要设置工具和流程。个人方面也可能需要说服人们遵守一些列约定，并在过程中建立信任。

这是从手动数据库部署过程到自动化过程可以采取的步骤的列表。

• 考虑从一个小的项目和团队开始。
• 为数据库生成基线模式。这可以手动完成（编写 SQL 脚本）或使用IDE生成。
• 将数据库脚本添加到源代码管理。
• 确定用于数据库更改和迁移的工具。
• 实现所选工具来处理版本控制的脚本。
• 为每个开发人员实现一个本地数据库
• 更新部署过程（或创建一个）以从源代码控制中的脚本生成数据库
• 更新部署过程以将脚本部署到下一个环境（例如 QA ）
• 实施自动化数据库测试。这可能是一大步。
• 更新部署过程以部署到您的下一个环境（例如 Pre Prod）
• 更新部署过程以允许用户在需要时（以及测试通过时）触发部署到生产环境
• 更新部署过程以自动部署到生产环境。

1. 前言​

在持续集成与持续交付（CI/CD）领域 Jenkins 是事实上的标准，随着云原生领域技术的发展，微服务架构下的持续集成与持续交付面临新的挑战。Jenkins 开源社区也开启了一个全新的项目 Jenkins X 来应对挑战。它基于 Jenkins 和 Kubernetes 实现，为微服务体系架构下的云原生应用的开发、运行和部署提供了全面的支持。相比于 Jenkins，Jenkins X 复用了 Jenkins 的能力，但更加专注于云原生应用的构建、测试和部署。

Tekton 是一个开源的、供应商中立的框架，用于创建持续集成和交付（CI/CD）系统，由持续交付基金会（CDF） 管理。作为 kubernetes 原生框架，Tekton 是通过为管道、工作流和其他构建块提供行业规范来实现持续交付的现代化。Tekton 允许通过抽象底层实现细节可跨多个云提供商或本地系统构建、测试和部署。

Tekton 和 Jenkins X 都是流行的持续集成/持续交付（CI/CD）工具，Jenkins X 更适用于那些已经熟悉 Jenkins 并希望将其扩展到云原生领域的团队。选择哪个工具取决于具体的项目需求、团队偏好以及团队对云原生技术的支持程度。

2. Tekton 的工作方式​

Tekton 的目标是在云原生环境中创建可重用、可组合和声明性的小型构建块。它使用步骤（Step）、任务（Task）、管道（Pipeline）和资源（Resource）来执行此操作，如下图所示。

图片来源于：developers.redhat.com

• Step 是对输入执行的操作。如果正在构建 Java 应用程序，它可能会运行一些单元测试或验证代码是否遵循现有的编码标准。Tekton 将在提供的容器中执行每个步骤。对于该Java 应用程序，可以运行安装了 JDK 的基础映像。Step 是 Tekton 中最基本的单元。

• Task 是按顺序执行的步骤列表。Tekton 在 Kubernetes 的 pod 中运行 Task，这允许在设计一系列相关 step 时拥有一个共享环境。例如，可以在任务中挂载一个卷，该卷将在该特定任务的每个步骤中共享。

• Pipeline 是可以并行或顺序执行的任务的集合。Tekton 为开发人员提供了如何以及何时执行这些任务的很大灵活性。甚至可以指定任务必须满足的条件才能启动下一个任务。

• Resource 大多数 Pipeline 需要执行任务的输入，也可以产生输出。在 Tekton 中，这些被称为资源。资源可以是许多不同的类型，如 Git存储库、容器映像或 Kubernetes 集群。

3. Tekton 安装​

先决条件：

• kubernetes 集群版本 >= v1.28
• kubectl 命令行工具
• 向当前用户授予集群管理员权限 Cluster-admin 。参见：Kubernetes role-based access control (RBAC)

kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

# Specific release
# kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/previous/<version_number>/release.yaml

# 当所有组件在 READY 列下显示1/1时，安装完成。如下图。按 Ctrl+C 停止监控
kubectl get pods --namespace tekton-pipelines --watch

安装 Tekton Command Line 工具

curl -LO https://github.com/tektoncd/cli/releases/download/v0.38.1/tektoncd-cli-0.38.1_Linux-64bit.deb
sudo dpkg -i ./tektoncd-cli-0.38.1_Linux-64bit.deb

4. 创建一个测试 Task​

sudo cat > hello-world.yaml << EOF
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: hello
spec:
  steps:
    - name: echo
      image: alpine
      script: |
        #!/bin/sh
        echo "Hello World" 
EOF

kubectl apply -f hello-world.yaml

sudo cat > hello-world-run.yaml << EOF
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: hello-task-run
spec:
  taskRef:
    name: hello
EOF

kubectl apply -f hello-world-run.yaml

# Verify that everything worked correctly:
# The value True under SUCCEEDED confirms that TaskRun completed with no errors.
kubectl get taskrun hello-task-run

# Take a look at the logs:
kubectl logs --selector=tekton.dev/taskRun=hello-task-run

5.接下来​

• Tekton 提供了一个 Web UI，参见官网 Dashboard 安装

• 可以在 Visual Studio Code 中安装 Red Hat 开发的插件 Tekton Pipelines

7.参考​

[1] Tekton 官网
[2] 持续交付基金会（CDF）
[3] 阿里云容器计算服务帮助文档-Tekton最佳实践
[4] Tekton Operator
[5] Visual Studio (VS) Code Tekton Pipelines extension by Red Hat

1.用 Burndown Chart（燃尽图）可视化项目进展​

燃尽图用于衡量工作进度，它反映的是完成的工作量以及剩余的工作量之间的关系。

下面是一个简单的燃尽图示例，这里为了简单起见，假设总共有 100 个任务项要完成，需要 10 天的时间来完成它们。用纵轴表示 100 个任务项，用横轴表示 10 天。

对于任何一项工作，最理想的方式是每天以一致的速率进行。在这种情况下，意味着每天要计划完成 10 个任务（10天*10个任务等于100个任务总数）。

实际上，如果第一天只完成了五个任务，第二天完成了四个任务，第三天完成了两个任务，则进度落后于计划，因为实际完成数少于了计划数，后续团队需要努力赶上，在接下来的几天里，会完成比原计划更多的任务，在项目结束时，燃尽图可能会如下所示：

2. 更实际一点的示例​

• 横坐标表示一个时间周期，这里表示一个 sprint 周期（15天）
• 纵坐标：左坐标轴表示待完成的工作量，右坐标轴表示每日完成的工作量（小时数或故事点数）
• 三条折线：
  • Ideal Trend（绿色）：理想线，假设按照固定速率每天完成 25 （小时或故事点）的趋势线。
  • Remaining Effort（Actual）（蓝色）：实际的完成工作进度。
  • Trend Line（Actual）（红色）：实际完成工作进度的趋势线。
• Daily completed：实际每天完成的工作。
• 在第7天之前，蓝色线在绿色线上方，表示开发进度落后。从第7天蓝色线在绿色线下方，表示进度逐步追赶上来。

3. 燃尽图的类型​

有几种类型的燃尽图常用于敏捷项目管理：

• Sprint 燃尽图：这种类型的燃尽图跟踪一个 Sprint 中剩余的工作。它帮助敏捷团队在短迭代期间监控他们的进度，并确保他们在设定的时间范围内按计划完成 Sprint 目标。
• 产品 Backlog 燃尽图：与 Sprint 燃尽图不同，产品燃尽图表示整个项目剩余的总体工作。它提供了项目维度进度的视图，并帮助项目经理和团队跨多个 Sprint 或迭代跟踪工作的完成情况。
• 发布燃尽图：显示了产品发版的所有计划功能和需求的进度。

4. 燃尽图有什么好处？​

• 监控工作进度：允许敏捷团队跟踪项目的所有剩余工作并预测何时完成。
• 告警：当偏离计划发生时提醒团队，以便及时采取纠正措施。
• 决策影响：显示项目期间做出的决策的效果，并为未来的决策提供信息。
• 沟通：促进团队和利益相关者内部的进度沟通，确保每个人都了解情况。
• 估计：帮助根据当前进度和趋势估计工作何时完成。
• 动机：通过展示进度和提供绩效反馈来鼓励团队成员表现得更好。
• 透明度：通过明确比较计划和实际进展来提高透明度。
• 协作：通过让每个人在项目状态和目标上保持一致来促进有效的协作。

5.燃尽图的局限性是什么？​

燃尽图的其它局限性还包括：

• 工作质量：燃尽图不能反映已完成工作的质量，因为它们只关注已完成任务的数量。
• 具体挑战：它们可能不反映项目期间遇到的具体挑战，这些挑战可能会影响整体进度。
• 复杂性：一些项目可能过于复杂，以至于燃尽图无法有效跟踪进度，尤其是当团队要求严格遵守敏捷方法时。
• 团队成员的压力：如果进度慢于预期，燃尽图会产生过度的压力，影响团队士气和动力。
• 学习曲线：对于刚接触敏捷方法的团队来说，学习使用燃尽图在敏捷框架内准确估计工作和管理任务可能需要时间并引入复杂性。

6. 燃尽图和燃起图（Burnup Chart ）的区别​

主要区别在于它们如何表示项目进度。

• 红线表示总的工作量，可以看到第6天的时候，发生了变更，总的工作量由 100 变到了 120。
• 绿线表示当前完成的工作量，最后项目完成时，两条线应该相交。

7. 敏捷和看板方法相关书籍​

• Learning Agile: Understanding Scrum, XP, Lean, and Kanban 1st Edition December 23, 2014
• Lean from the Trenches: Managing Large-Scale Projects with Kanban 1st Edition December 21, 2011
  • 精益开发实战:用看板管理大型项目 2012-09-01
• Kanban: Successful Evolutionary Change for Your Technology Business Blue Book ed. Edition April 7, 2010
  • 看板方法：科技企业渐进变革成功之道 2014-02-01

1. 用 Cumulative Flow Diagram（累积流图）可视化项目进展​

我们希望团队尽可能高效地工作，但是掌握事情的真正进展可能很有挑战性。累积流图是敏捷、精益、Scrum、看板和 SAFe 方法中使用的管理工具，用于随时间可视化和分析工作项流程。可以直观的了解团队的工作情况，以便可以弄清楚如何改进它。

2. 累积流图示例​

下面是一个累积流图的示例

累积流图纵轴（表示任务或工作项）、横轴（表示时间间隔）、不同的彩色线或带（表示各个开发阶段）

3. 累积流图可以反映的指标​

有四个主要的指标是我们应该关注的，通过了解和跟踪这些指标，可以识别流程效率低下的地方并进行改进。

• Lead Time 交货时间，任务从流程开始到完成的时间。它是一个重要的指标，因为它揭示了瓶颈在哪里，并提高了交付的可预测性。假设您在晚上8:00下了晚餐订单，您的订单在晚上8:30送达。在这种情况下，您的交货时间是30分钟。这是从您提出请求的那一刻起到您收到请求的这段时间。
• Cycle Time 周期时间，是完成一个任务花费的时间。假设厨房在晚上8:10收到了，厨师开始准备你的订单。你在晚上8:30收到食物；在这种情况下，你的周期时间是20分钟。这是处理你的订单所需的实际时间。
• WIP（Work in progress）进行中的工作（在制品）
• Throughput 吞吐量，团队在指定时间段内交付了多少工作

参考​

[1] Lead time and Cycle Time and the importance of Flow in Kanban
[2] Kanban Metrics: An Overview of the Most Important Kanban System Metrics to Track
[3] Cumulative Flow Diagram
[4] How to read a cumulative flow diagram
[5] What Is a Cumulative Flow Diagram?
[6] [PDF]The Ultimate Guide To Reading The Cumulative Flow Diagram

在项目实施过程中，会在各个时间阶段有各种可能的事项要与客户进行沟通或者谈判，通常可能主要是下面几项：

• 开发报价
• 交付里程碑与时间进度
• 系统的设计、架构、解决方案或技术实现方式
• 需求范围变更
• 日常工作的方式

需求范围变更，通常是这些事项中最主要的，也是对项目顺利交付影响最大的因素。

在与客户沟通谈判时，有一些原则、方式或方法可以遵循。

1. 定义明确的界限​

在项目启动阶段要与客户对一些基础事项形成一致意见，例如：系统的功能目标、总体的里程碑计划、处理接受变更的流程、验收的标准、输出的交付物等。与客户达成一致，这样就有了一个基础的界限边界。

在与客户进行沟通时我们就有了一个这样的基础。如果客户要求更改，要参考这些文件。根据项目的目标、时间来评估。这不是对客户说不，而是引导客户理解所涉及的影响，双方一起来做权衡。

2. 了解客户需求，提供替代方案​

可以通过提出开放式问题、积极倾听和总结客户的想法。仔细审查他们的要求、时间和预算，并澄清任何模棱两可或理解上的偏差。了解客户的需求将有助于使自己的建议与他们的期望保持一致，并向客户展示价值和可信度。

在对范围变更做出任何决定之前，评估它们对项目的影响。考虑这些变更将如何影响进度、资源和最终产品的质量。提议的变更是否与项目目标一致，是否值得额外的时间和精力。如果影响太大，可能需要找到一个折衷方案，在不过度资源投入的情况下满足项目目标。

面对迫在眉睫的最后期限，要确定任务的优先级。必须确定哪些功能或任务对项目的成功至关重要，哪些可以推迟或完全放弃。与客户一起根据任务的紧迫性和重要性对任务进行分类。这将指导我们就范围变更做出明智的决定。

当客户要求更改时，必须传达这将对项目时间进度和成本资源产生的影响。解释一个更改可能对项目的各个方面产生的连锁反应。使用清晰的非技术语言来阐明为什么更改可能需要额外的时间或预算。通过使后果具体化，客户更有可能理解额外资源或时间调整的必要性。

提供一个替代的方案，也许可以在系统上线以后的运行阶段再考虑逐步引入新的功能，也许那时的想法会跟现在不同。或者在产品的下一期开发中对其进行改进。与客户一块寻找可能的解决方案。

也许最终我们可以同意这些额外的变更工作，但要协商延长最后期限或额外付款来支付额外的工作。这期间是有非常多的谈判技巧可以运用（参见下面小节 5. 学习利用一些谈判技巧）。

3. 寻求客户高层利益相关者的支持​

客户的高层利益相关者才是对项目具有决定权，要让高层利益相关者充分了解项目当前的情况，了解其真实的想法，并寻求支持。

4. 寻求商务支持​

最后，也需要保持一定程度的灵活性。在软件项目管理中，变化通常是不可避免的。虽然管理范围变化很重要，但过于僵化会给客户关系带来不好的影响。

当处于僵局时，需要寻求商务支持，大量事实表明，事情在商务层面沟通时，仿佛进入了另一个维度，很多难题也有了解决办法。

5.学习利用一些谈判技巧​

罗杰·道森（Roger Dawson）作为国际首席商业谈判大师，以其丰富的谈判经验和深刻的洞察力，创作了广受欢迎的谈判指导书籍《优势谈判》。这本书不仅在全球销量超过1000万册，而且被广泛应用于各种商业和日常谈判场合。

书中介绍了一些谈判技巧，以下是部分标题摘录:

开局谈判技巧

• 开出高于预期的条件：强调在谈判开始时提出高于自己期望的条件，以争取更多的谈判空间。
• 永远不要接受第一次报价：阐述为何不应立即接受对方的首次报价，并探讨如何有效应对。
• 学会感到意外：通过表现出对对方条件的惊讶，来影响对方的谈判策略。
• 避免对抗性谈判：倡导通过合作而非对抗的方式来解决分歧。
• 不情愿的卖家和买家：利用“不情愿”的策略来增强自己的谈判地位。
• 钳子策略：通过要求对方做出改变来逐步缩小双方的差距。

中场谈判技巧

• 应对没有决定权的对手：识别并应对那些没有最终决策权的谈判对手。
• 服务价值递减：讨论在谈判过程中逐步减少让步的价值。
• 绝对不要折中：解释为何折中往往不是最佳解决方案，并探讨更有效的策略。
• 应对僵局：提供解决谈判僵局的方法和技巧。
• 应对困境：讨论在谈判中遇到困境时的应对策略。

终局谈判策略

• 白脸—黑脸策略：分析并应对这种常见的谈判技巧。
• 蚕食策略：在谈判即将结束时提出小要求，以逐步达到自己的目标。
• 如何减少让步的幅度：探讨在谈判中如何以最小的让步换取最大的利益。
• 收回条件：在必要时收回之前提出的条件，以重新掌握谈判的主动权。
• 欣然接受：学会在适当的时候接受对方的条件，以达成双赢的谈判结果。

在 Kubernetes 中不提供负载均衡的实现，网络负载均衡器的实现依赖于云厂商（阿里云、腾讯云、华为云、AWS、Azue 等），如果是自建集群，而不是选择这些公有云厂商提供的 Kubernetes ，在创建 Service 时，我们只能使用类型是 NodePort 和 ExternalIPs 的服务用做外部访问。

我们希望自建集群也能简单便捷的方式对集群外部暴露服务，MetalLB 这个项目正是为了解决这个问题。

先决条件​

安装前有几个先决条件需要查看，特别是网络插件（CNI）的兼容性支持。

官网的安装文档 MetalLB Installation

安装​

修改 kube-proxy 参数

kubectl edit configmap -n kube-system kube-proxy

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  strictARP: true

安装MetalLB

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.8/config/manifests/metallb-native.yaml

查看命名空间下的组件都正常运行

kubectl get all -n metallb-system

定义要分配给负载均衡器服务的IP地址并配置 2 层通告。

sudo cat > metallb-config.yaml << EOF
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 10.10.0.150-10.10.0.200
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: example
  namespace: metallb-system
EOF

kubectl apply -f metallb-config.yaml

测试​

kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --type=LoadBalancer --port=80

# 可以看到这里分配的地址是 10.10.0.150
kubectl get svc

curl http://10.10.0.150

参考​

[1] 创建外部负载均衡器
[2] 组件工具 kube-proxy
[3] IPVS vs. IPTables for kube-proxy in Kubernetes
[4] Comparing kube-proxy modes: iptables or IPVS?