自动化 (Automation)

云原生领域中GitHub开源Go项目的自动化测试实践与策略 介绍 作为 Github 上的 热门项目 OpenIM，如何在云原生时代中创造出价值，这是非常重要的，OpenIM 是一个优质的小团队，我们在自动化中并没有特别深入的见解。 使用 GitHub Actions 进行持续集成和持续交付 (CI/CD): GitHub Actions 提供了一个平台，可以自动构建和测试 Go 语言项目。通过配置 GitHub Actions 工作流，你可以在代码更改时自动运行测试，确保代码的质量和功能。 KubeVela 项目实践: KubeVela 是一个 Go 语言的云原生和开源项目，它展示了如何在云原生环境中组织 CI/CD 过程，包括自动化测试。KubeVela 使用声明性工作流来协调 CI/CD 过程，你可以参考 KubeVela 的 GitHub 仓库来理解和应用这些实践34[5](https://github.com/kubevela/workflow#:~:text=KubeVela Workflow is an open,engine in your own repository)。 云原生测试框架与工具: 在云原生开发中，合约测试（Contract Testing）是一种常见的测试实践，它确保服务间的通信符合预定义的 API 协议。例如，Cloud-Native Toolkit 中使用 Pact 进行合约测试。通过编写和集成测试，你可以验证服务间的通信是否符合预期6。 代码覆盖率检查: 在进行自动化测试时，检查代码覆盖率是一个好的实践。许多测试框架内置了代码覆盖率检查功能，可以配置它们来报告测试的代码覆盖率。例如，使用 SonarQube 工具来读取和报告代码覆盖率信息6。 利用开源工具和框架: 你可以利用开源工具和框架来进行测试，例如使用 Cypress 进行云原生应用的测试[7](https://dev....

DevOps DevOps 🔥 DevOps是一种软件开发和运营的文化和方法论，旨在通过自动化和协作来缩短软件开发周期和提高软件质量。 DevOps（Development和Operations的混成词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 为什么 OpenIM 需要 DevOps？ 我想用一句话来概括，DevOps 能解决 OpenIM 当前的团队管理，能高效组织团队，并且能通过 自动化 工具协作于沟通。 从而实现用更少的浪费、更频繁的交付更稳定的产品。 最开始的 OpenIM 是什么样子的？ 找到了之前的一个很古老的版本，链接是：https://github.com/OpenIMSDK/Open-IM-Server/tree/test-tuoyun 几乎存在 commit 信息丢失，因为信息不全导致代码无法跟踪问题，导致文档缺失，代码不规范等一系列的问题。 我们跨越了从原始社会到传统的协作方式，再到后面的 devops 为什么说及时到现在，我依旧没有将 OpenIM 转变为 devops，一个很明显的判断标准，每一次运维和交互工作依旧需要我手动去做，无疑是区分了 dev 和 ops 的职责。不仅仅让成本变高，效率变低，更重要的是团队没有了更清晰的定位。 那么我后面的计划如何？ 不管是 prow, actions, 等等 CI 工具，以及各种 ops（gitops, aiops, chatops,） 也不管是各种设计的 自动化 以及 自动化管理工具，自动化交互工具。 无疑他们是一套体系： 提供无感知的开发环境，无论交付是否频繁，每一个 feature 的 PR 都能快速的，规范并且经过大量自动化测试，更加快速上线，也能更快地响应客户需求。每一次发布的变更变少，所以风险，以及合并的冲突，工作量就变少。而且代码 code review 更方便，代码质量和团队水平提升很高的档次。 🔥 OpenIM 当时我的设计理念是 main 分支作为一个类似于传统的 dev 分支，保证代码的最新以及基本可靠，release-v* 分支作为稳定的分支。 DevOps 最重要的就是自动化，和自动化运维。非常鼓励自动化，甚至可以让开发者即使不会任何运维也能去走整套自动化的流程。 OpenIM 的团队约束制定：https://traveling-thistle-a0c.notion.site/OpenIM-standardization-ebd0c1529ab54e4fb92840e67a73aac1?pvs=4...

创建 actions actions 是可以联合收割机以创建作业和自定义工作流的单个任务。您可以创建自己的操作，或使用和自定义GitHub社区共享的操作。 可以通过编写自定义代码来创建操作，这些代码可以以您喜欢的任何方式与您的存储库进行交互，包括与GitHub的API和任何公开可用的第三方API集成。 可以编写自己的操作以在工作流中使用，或与GitHub社区共享您构建的操作。要与所有人共享您构建的操作，您的存储库必须是公共的。 操作可以直接在机器上或Docker容器中运行。您可以定义操作的输入、输出和环境变量。 可以构建Docker容器、JavaScript和复合操作。操作需要一个元数据文件来定义操作的输入、输出和主入口点。元数据文件名必须为 action.yml 或 action.yaml 。有关更多信息，请参阅“GitHub操作的元数据语法。“ docker 容器操作 Docker容器用GitHub Actions代码打包环境。这创建了一个更加一致和可靠的工作单元，因为操作的使用者不需要担心工具或依赖项。 Docker容器允许您使用特定版本的操作系统、依赖项、工具和代码。对于必须在特定环境配置中运行的操作，Docker是理想的选择，因为您可以自定义操作系统和工具。 对操作进行发布管理 如果您正在开发供其他人使用的操作，我们建议使用发布管理来控制分发更新的方式。 用户可以期望操作的修补程序版本包括必要的关键修复程序和安全修补程序，同时仍与其现有工作流保持兼容。每当您的更改影响兼容性时，您应该考虑发布新的主版本。 在这种发布管理方法下，用户不应该引用操作的默认分支，因为它可能包含最新的代码，因此可能不稳定。 相反，您可以建议用户在使用您的操作时指定一个主要版本，并且仅在遇到问题时才将他们引导到更具体的版本。 要使用特定的操作版本，用户可以配置他们的GitHub操作工作流，以针对标签，提交的SHA或以发布命名的分支。 使用标签进行发布管理 我们建议使用标签进行操作发布管理。使用此方法，您的用户可以轻松区分主版本和次版本： 在创建发布标签（例如 v1.0.2 ）之前，在发布分支（例如 release/v1 ）上创建并验证发布。 使用语义版本控制创建发布 文件列表的右侧，单击Releases 页面顶部，单击草拟新版本。 要为发布选择标签，请选择选择标签下拉菜单。 如果您创建了一个新标签，请选择目标下拉菜单，然后单击包含您要发布的项目的分支。 在“描述此版本”字段中，为您的版本键入描述。如果您在描述中 @mention 任何人，发布的版本将包含一个贡献者部分，其中包含所有提及用户的头像列表。或者，您可以通过单击生成发行说明自动生成发行说明。 或者，要在您的版本中包含二进制文件（例如已编译的程序），请在二进制文件框中拖放或手动选择文件 或者，选择设置为最新版本。如果不选择此选项，将根据语义版本控制自动分配最新版本标签。 如果您准备好发布您的版本，请单击发布版本。要稍后处理该版本，请单击保存草稿。然后，您可以在存储库的发布提要中查看已发布或草稿的发布。有关详细信息，请参阅“查看存储库的版本和标签”。 移动major version标签（例如 v1 、 v2 ），指向当前版本的Git ref。例如： git tag -a v1.4 -m "my version 1.4" 引入新的主要版本标记（ v2 ），用于将破坏现有工作流的更改。例如，更改操作的输入将是一个突破性的更改。 主要版本最初可以使用 beta 标签发布，以指示其状态，例如 v2-beta 。 -beta 标签可以在准备好时移除。 带有查询参数的发布表单自动化 要通过使用自定义信息自动填充新发布表单来快速创建发布，您可以将查询参数添加到发布表单页面的 URL。...