Skip to main content

· 8 分钟阅读

Choerodon 猪齿鱼全场景效能平台,是基于 Kubernetes,Istio,knative,Gitlab,Spring Cloud 来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps 等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

2019 年 7 月 1 日,Choerodon 猪齿鱼发布0.18版本,本次更新新增了部署配置,并对故事地图进行了重构,欢迎各位更新体验。

  • 发布版本:0.18
  • 发布时间:2019 年 7 月 1 日
  • 更新范围:知识管理、敏捷管理、持续交付、测试管理以及微服务开发框架

下面就为大家带来详细的版本更新介绍。

新增功能

知识管理

  • 支持版本回滚以及版本对比。
  • Wiki 空间中文章全部迁移到知识管理中。
  • 文档可以进行链接的分享。
  • 支持 word 的导入,导入后支持预览。
  • 页面支持导出 pdf。

敏捷管理

  • 本版本对用户故事地图进行了重构,包括:
    • 支持规划故事类型;
    • 支持切换版本泳道,所有在故事地图和需求池中的问题将会按照版本的不同来展示。

  • 在故事下可以快速创建子任务。
  • 新增人员类型的自定义字段。
  • 新增自定义字段修改的活动日志

持续交付

  • 部署流水线模块新增部署配置功能,支持在此创建部署配置用于应用部署或创建自动部署任务时选择。

  • 部署流水线模块流水线部分新增站内信消息用于通知流水线相关人员去执行对应的操作。

  • 部署流水线模块流水线详情页面新增流水线的状态显示与对应的操作按钮。
  • 部署流水线模块流水线管理界面与总览界面新增“快速搜索”和“与我相关”的筛选框。
  • 部署流水线模块实例部分新增实例关联的网络和域名的界面,支持在此创建和查看与此实例相关的网络和域名。
  • 部署流水线模块创建证书页面新增上传证书的模式选择,并新增了对证书文件的校验。
  • 部署流水线模块环境总览页面 GitOps 日志部分,新增重试 GitOps 的按钮。

测试管理

  • 新增自动化测试列表页自动刷新功能。

微服务开发框架

  • 修改密码菜单新增 gitlab 修改仓库密码入口。
  • 应用管理添加创建和查看 token 功能,以便于在 feedback 中识别应用身份。

功能优化

知识管理

  • 文章的保存优化。
  • 编辑处理的优化。
  • 问题关联文档修改为关联知识文档。

敏捷管理

  • 优化部分接口性能。
  • 对于平台中已经停用的用户,人员列表不再显示。
  • 父任务可以看到所有子任务状态的进度条。
  • 部分页面样式优化。
  • 部分报表优化。

持续交付

  • 优化了开发流水线模块代码质量页面 SonarQube 的查询。
  • 优化了开发流水线模块创建分支的操作。
  • 优化了部署流水线模块流水线部分的权限问题。
  • 优化了实例界面的查询速度。
  • 优化了从 GitLab 和 Github 导入应用时只导入 master 分支的问题,现在会默认将所有分支导入。
  • 优化了应用市场中应用已发布版本的查询速度。

测试管理

  • 优化测试用例详情默认展开。
  • 微服务开发框架。
  • 优化用户信息显示样式。
  • 登录页去除跳转手机端页面。
  • 优化任务明细排序方式为优先按状态排序。

缺陷修复

知识管理

  • 修复保存文章时会将名称更改为上一篇文章名的问题。
  • 修复知识管理中表格单元格合并后显示错乱的问题。

敏捷管理

  • 修复问题导入描述字段特殊字符报错。
  • 修复版本名称为空的版本也可以创建的问题。

持续交付

  • 修复了 ConfigMap 传递值为空的问题。
  • 修复了开发控制台页面工作台中分支的查询问题。
  • 修复了 Redis 容器 shell 里面进入 redis 命令行,格式有误的问题。
  • 修复了流水线失败后点击重试引起的问题。

测试管理

  • 修复色块报表空数据异常。
  • 修复测试计划中测试执行排序异。

微服务开发框架

  • 修复菜单分析数据显示异常的问题。

删除

知识管理

  • 删除空间/页面/评论 API 调整权限。

持续交付

  • 移除了流水线部分的部署配置,将其置于了部署流水线模块之中。

微服务开发框架

  • 移除平台层对项目分类的维护。

社区参与

感谢以下这些朋友在社区论坛中提出反馈和意见,在 0.17 版本更新中作出突出贡献。

  • @lisen2023
  • @suyoyo
  • @phoenix

更加详细的内容,请参阅Release Notes官网

欢迎各位朋友通过 Choerodon 的GitHub猪齿鱼社区进行反馈与贡献,帮助 Choerodon 猪齿鱼不断成长。Choerodon 会持续优化,敬请期待

欢迎加入 Choerodon 猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。

· 12 分钟阅读

本篇将为大家介绍如何将应用导入到 Choerodon 猪齿鱼。Choerodon 平台上导入应用有两个入口,第一个入口在应用管理页签内,是从 gitlab/github 导入应用,第二个入口在应用市场中,可以在其它平台的应用市场导出后再导入。

为什么要从外部代码管理平台导入应用

Choerodon 平台最开始发布的版本中只有应用市场的导入功能,后来在版本迭代中,越来越多的用户开始搭建并使用了 Choerodon 平台,其中包含了很多其他软件公司。而且这些软件公司有一个共同点,在了解 Choerodon 平台之前,他们的日常开发,产品的迭代已经使用上了 gitlab,所以他们的代码仓库都存在已有的 gitlab 上。

由于 Choerodon 平台与 gitlab 的高度耦合,Choerodon 平台的组织、项目、用户等都和 gitlab 的组、用户等资源一一对应的。Choerodon 的数据库中存了大量两者的中间关系表。所以 Choerodon 一般不建议直接将已有的 gitlab 迁移到 Choerodon 的 gitlab,一方面,gitlab 版本不一致,可能导致迁移失败;另一方面,中间会缺少很多关键数据,严重影响后续的其他功能。在 Choerodon 社区中也有很多用户自行写了脚本去迁移,或者直接迁移数据库,迁移的过程步骤很繁琐复杂,都或多或少出现了问题,出于此,Choerodon 才开发了从 gitlab 或者 github 导入应用到 Choerodon 平台的功能。

在介绍应用导入方法之前,先简单介绍一下应用的代码仓库组成。

Choerodon 代码仓库的主要组成

  1. 各种开发语言或者开发框架的基础代码

  2. Chart 文件夹:Choerodon 持续交付中的应用部署用的是 K8S(开源的容器集群管理系统),helm 是 K8S 一个软件包管理工具,里面存放了大量的 chart 包,每个 chart 包可以定义各种应用部署所需要的 K8S 对象文件,Chart 文件夹就是用来存放打包成 chart 包的文件。

  3. DockerFile:用来打包应用到镜像中,容器化应用,在各种流行的系统中部署,例如 linux,windows 等。

  4. Gitlab-ci.yaml:gitlab-ci 文件是 gitlab runner 所执行的脚本文件,里面可以定义各种脚本,比如在 Choerodon 中各种应用的打包,以及镜像的生成与推送,chart 包的打包与推送都是放在 gitlab-ci 文件中实现。

应用市场中的应用导入

应用市场里面的应用导入,是指从其他 Choerodon 平台的应用市场中导出应用之后,再在自己的 Choerodon 平台中导入。导入导出的内容是一个 tgz 包,里面包含了应用的一个或多个版本对应的 chart 包,导入成功之后,会生成一个没有代码仓库的应用,同时给该应用生成指定的版本。但不能对该应用进行开发生成新版本,应用部署时只能部署导入应用的指定版本。

为什么应用市场中可以导入应用

在自己的平台中,如果开发者的一个服务依赖于 mysql,但是自身平台下并没有开发部署 mysql 的团队,若此时恰好另外一个平台开发了 mysql 应用,就可以在自己的本地下新建一个 mysql 应用,把另外一个平台的 mysql 代码仓库拷贝过来,然后生成版本部署供自己使用。

这个过程很麻烦很繁琐,而且在一段时间内,开发者不会对这个应用进行开发,只需要使用,除非有版本大的更新,这大大消耗了人力物力。Choerodon 的部署是基于 helm chart 的,部署应用只需要对应版本的 chart 包 ,如果提供一个上传下载 chart 包的途径,就能直接拿到 mysql 的 chart 包,然后上传到自己的 chartmusume 仓库中,就可以在本平台进行部署了 。基于这个原因,有了猪齿鱼应用市场以及应用的导出导入功能。

应用市场导入导出的原理

当其他 Choerodon 平台一个应用发布到应用市场之后,可以选择导出应用的一个版本或多个版本的 chart 包(从 chartmusume 仓库中下载下来)和应用的相关信息 json 文件,以及各应用版本的 docker 镜像信息,将其打包成一个 zip 文件。

然后在本 Choerodon 平台中,将之前导出的 zip 导入,此时会解压该 zip 包 ,将其中的应用以及应用版本信息存入数据库中,将其中的 chart 包上传到本平台的 chartmusume 中,将应用版本的 docker 镜像从其它平台的 harbor 库拉取下来,并推送到自己的 harbor 仓库中(如果其它平台镜像不是公开的)。

之后就可以在本平台对于该应用的特定版本进行部署了,简单示例图如下:

应用管理中的导入应用

应用管理里面导入的应用是指从外部代码管理平台(gitlab/github)导入已有的应用到 Choerodon 平台,根据导入时选择的模板类型生成对应的 dockerfile,chart 文件夹,gitlab-ci.yaml 文件。该应用有对应的代码仓库,可以在已有基础上进行开发,并能通过 gitlab 的持续集成生成各种版本,用作后续的部署。

外部应用导入步骤

第一步:应用导入需要填写来源应用的仓库地址,如果之前的代码仓库来源于 github 的仓库,或者 gitlab 的公开仓库,那么不需要填写授权 token,如果是 gitlab 的私有仓库(大部分)则需要填写具有 clone 仓库权限的用户 token。

第二步:填写好名称、编码,选择指定的模板(会根据指定的模板找到指定类型的 dockerfile,charts,gitlab-ci.yaml 文件嵌入到已有的代码仓库中)

第三步:选择特定项目成员或所有项目成员拥有该应用的权限,用于权限隔离

第四步:进行 harbor 仓库和 chart 仓库设置(如无特殊需求,使用默认即可),然后点击导入即可。

外部应用导入实现逻辑

首先将填写的源仓库地址使用 jgit,(jgit 提供了一套类似 Git 命令的 Java API,可以方便地在程序中进行 git 操作)克隆到本地缓存中,填写完仓库地址和 token 之后会校验填写的 token 是否有权限克隆,没有权限则会提示无权限。

然后根据填写的编码去 gitlab 对应的组下面创建一个空的 gitlab project(包含 webhook,以及 ci 需要的 token),再根据所选的应用模板类型去将 Choerodon 模板库克隆模板到本地缓存,并找到模板中的 dockerFile 文件,chart 文件夹,gitlab-ci.yaml 文件。

将找到的模板中的文件赋值到源仓库本地缓存的各个分支中(此过程会校验是否存在对应内容,有则不复制)。之后使用 jgit 操作每个分支,git add , git commit,,更换源仓库的远程 remote(远程 remote 地址为之前在 Choerodon 关联的 gitlab 创建的空 gitlab project 仓库地址)。

最后使用 git push 将合并到好代码推送上去,逻辑图大致如下:

应用导入成功之后,会将原来代码仓库所有的分支,以及分支所有的 commit 记录导入到新的 Choerodon 平台关联的 gitlab 中,并会在数据库中增加对应的记录,实现应用的无缝迁移。

更多 Choerodon 猪齿鱼持续交付相关文章 ▼

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

· 10 分钟阅读

在上一篇关于自动化测试的文章 解密敏捷自动化测试 中,为大家介绍了敏捷自动化测试,以及 Choerodon 猪齿鱼自动化测试的落地。在这篇文章中,给大家介绍一下 Choerodon 自动化测试的技术方案的设计思路以及实现。

为什么自动化测试需新建测试应用

自动化测试的本质是使用一些测试框架开发测试代码,运行测试代码即对已有的业务应用进行相应的测试。对于一个项目来说,测试应用与普通的业务应用应该是同等重要的。

从代码开发上来说,一个自动化测试应用的代码量可能比一般的业务应用要大,多人协作开发也是目前自动化测试的大趋势,所以代码托管可以更好地进行测试代码开发与维护。

之前有用户来咨询,在测试应用与业务应用的对应关系上是如何落地实践的。是否需要每个业务应用都需要对应一个测试应用。猪齿鱼平台本身是基于微服务架构进行开发的,它有很多的后端服务,但这些中有一些的耦合度是比较高的。所以在开发人员的测试实践过程中,并没有针对每个应用一一对应建立测试应用,而是基于大的功能模块进行拆分。比如敏捷管理模块有一个 mocha 框架的测试应用,测试管理模块也有一个。像这样基于大功能模块的拆分免去了很多 feign 内部调用重复测试的冗余测试代码,且易于进行测试代码开发的任务分配。

为什么自动化测试应用要执行 GitLab CI

在 Choerodon 的 DevOps 模块控制下,当一个应用提交代码后触发一次 GitLab CI,就会为这个应用生成一个版本号,并打出可以部署运行的镜像、Chart 包,对于测试类型的应用也是如此。Choerodon 的自动化测试运行也是基于 helm 进行的部署操作,对应的,也需要对于代码进行构建打包。

并且,测试管理模块对于自动化测试用例的回扫功能是基于测试报告文件以及代码注释进行的(这部分在本文最后章节会进行展开介绍)。对测试代码进行版本控制也就意味着对测试用例进行了版本控制。在一个测试应用可能被定时、反复运行的场景下,如果能保证已有测试用例的时效性并且加以复用就可以最大程度上减少冗余数据的产生。Git 的版本控制刚好就可以保证相同版本下的代码一致性。

Choerodon 提供的模板有什么特别之处

Choerodon 平台现在提供了三个测试应用的模板,分别是 mocha+chai,TestNG+Assured,TestNG+Selenium。

这些测试模板都对于 helm chart,Dockerfile,gitlabci 等进行了加工,并在其中封装了简单的 demo 代码,例如登录接口测试的简单实现。通过 demo 代码可以快速上手进行测试代码的开发。

并且为了方便对“测试数据”,“预期结果”这两个测试步骤的字段进行维护,我们对官方提供的可以在测试报告中加注释的方法进行了封装并进行数据提取,可以满足步骤信息的维护需求。

这其中 TestNG+Selenium 的模板通过对于官方镜像的修改,支持了在部署过程中独立启动 chrome-standalone 浏览器核心。猪齿鱼基于官方 chrome-standalone 镜像的基础上加入了 servlet 的生命周期管理,可以通过接口调用的形式对浏览器核心的进程进行管理。在 TestNG+Selenium 的应用部署时,一个 pod 对象中存在两个 containers 对象,其中一个是 WebDriver 浏览器核心,一个是我们的 TestNG 应用。后者基于 pod 中的内网进行浏览器核心调用,并在 Dockerfile 的最后通过 curl 结束 WebDriver 的生命周期。这样就省去了 Selenium 框架对于外部浏览器核心的依赖需求。

如下图所示:

w

拉取模型 OR 推送模型

在 Choerodon 如何运行自动化测试这个问题的选型初期,使用推送模式还是拉取模式一直是一个比较纠结的问题。团队研究过 GitLab CI、qTest 等平台的部署运行方案并进行了参考,而他们的定位、出发点和猪齿鱼平台又不尽相同。

例如在 GitLab 中他们的方案是单独部署 runner,即需要部署一个 agent 主动进行任务拉取然后调度执行返回结果。而这样的方案无疑会增加部署的成本,就像我们自己搭建一个 GitLab 一样,搭建好了并没有 runner 节点可以直接使用,而是需要额外进行 runner 的搭建与注册到 GitLab 平台的操作。这样提高搭建成本的操作对于本身搭建要求已经较高的猪齿鱼平台来讲并不是非常友好。

所以猪齿鱼选型的最终结果是使用推送模式进行自动化任务的处理。用户在激活自动化测试运行的时候由测试管理模块后端发送请求至 DevOps 模块后端,然后通过 WebSocket 连接 agent 进行任务调度。并将自动化测试功能集成在现有的集群 agent 上,可供用户选择运行自动化测试的环境即为环境流水线中注册的环境。从而减少平台的组件数,并且降低搭建的成本。

测试结果是如何进行回扫的

Choerodon 测试管理模块对于自动化测试结果的处理是在测试应用的 Dockerfile 中通过 curl 访问测试管理模块的接口,将测试报告打包并回传测。在接收到文件后并将其保存加以解析从而导入到测试用例、测试执行中的。

例如 TestNG 框架,将 Suite 级别对应成一个用例文件夹,那在一个 Suite 中的 Java 类即为一个测试用例,这个类中的方法就是这个用例的测试步骤。并且解析 ReporterUtil 类中打印在 xml 报告中的日志对结果、预期字段进行填充,就完成了测试用例的扫回。

在有了测试用例之后就为其新建测试阶段,然后按照测试报告的结果进行测试执行状态的更新。如有报错日志等信息都会维护在对应步骤的注释字段中。

测试结果扫回逻辑如下图:

w

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

· 7 分钟阅读

Choerodon 猪齿鱼作为一个微服务框架需要解决微服务数据初始化本身具有的问题和复杂性,同时也需要满足框架本身特有的数据初始化需求,下面为大家介绍一下这方面的设计思想和实现。

微服务的数据初始化难题

先来看一下在微服务的数据初始化中常见的几个问题。

▍1.1 表结构的初始化和可平滑升级

表结构的定义在数据库初始化中是重中之重,它涉及到整个服务运行和利用数据库实现功能的方式,一般来说表结构定义和升级涉及到以下操作:创建表,创建字段,创建索引,修改索引,修改字段,重命名表,删除索引,删除字段,删除表。这些操作如果都需要对多种数据库进行兼容和可平滑升级,那么复杂度就会突然增加,基本不可能像传统应那样通 SQL 脚本进行管理,而猪齿鱼面临的就是这种情况。

▍1.2 跨服务数据的自动初始化

在微服务架构中,不可避免的会出现需要将数据初始化到其他服务的场景,比如猪齿鱼的大部分服务都需要初始化菜单数据到 IAM 服务,处理菜单列表的请求是由 IAM 服务处理的,然而对于微服务的部署而言,很多时候又不能运行初始化数据的时候连接多个数据源从而产生问题。而且微服务的部署可能不是全量的,存在这个部署不需要这个服务的情况,这种情况的初始化又需要修改初始化的脚本或者程序带来复杂性。

▍1.3 繁琐的编码化数据的自动发现

数据的初始化中有一类数据是可以从代码或者文档,或者其它地方收集提取出来的,并且这部分数据往往比较繁琐和庞大,比如在猪齿鱼中的权限鉴定需要 URL 与 Controller,Method 的映射关系,这部分数据如果手工进行初始化会产生很大的工作量,并且在实际代码修改后可能初始化数据没有更新产生问题。

猪齿鱼的本服务数据的初始化

认识到这些问题后接下来再来介绍一下猪齿鱼在多次迭代后对这些问题提出的解决方案。先来看对于本服务数据初始化的解决方案,这部分的具体实现可以参考开源代码:https://github.com/choerodon/choerodon-starters/tree/master/choerodon-liquibase

▍2.1 数据表结构的初始化

对于数据库表结构的初始化猪齿鱼采用 Liquibase 开源项目,具体为使用 Liquibase 的 Groovy DSL,增强了 Liquibase 的灵活性,并且 Liquibase 本身支持平滑升级和多数据库支持解决了表结构初始化的问题。

▍2.2 本服务预置数据的初始化

对于一些预置数据,包括预置的用户角色,以及自动化测试执行时候需要的预置数据,猪齿鱼使用 Excel 来辅助初始化的数据,方便操作,填充,关联。

猪齿鱼的跨服务数据的初始化

下面再看一下猪齿鱼关于跨服务数据初始化和自动发现数据的处理方式。

▍3.1 自动发现数据的初始化

服务启动后通过管理服务访问各个服务的通用接口从 ClassPath 中获取数据通过分布式事务进行初始化。

具体代码参考:https://github.com/choerodon/manager-service/blob/master/src/main/java/io/choerodon/manager/api/eventhandler/EurekaEventObserver.java

▍3.2 跨服务预置数据的初始化

使用与本服务预置数据一样格式的 Excel 进行填写数据,编译时将 Excel 转化为 Json 数据,最终和自动发现数据一同通过分布式事务初始化。 其中编译时将 Excel 生成 Json,并且通过 Maven 的依赖关系进行合并使用了猪齿鱼 Maven 插件,具体代码参考:https://github.com/choerodon/choerodon-starters/tree/master/choerodon-maven-plugin

结语

猪齿鱼数据初始化的方式从早期的 SQL 脚本,到 Liquibase,再加上为了满足菜单初始化需要而设计的独立 Python 初始化工具,在 0.17.0 版本中统一升级为 Liquibase Groovy + Excel 的形式,解决了目前遇到的所有问题。以上就是猪齿鱼数据初始化的整个迭代过程和实现思路,谢谢大家。

更多 Choerodon 猪齿鱼微服务相关文章 ▼

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

· 8 分钟阅读

Choerodon 猪齿鱼全场景效能平台,是基于 Kubernetes,Istio,knative,Gitlab,Spring Cloud 来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps 等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

2019 年 6 月 3 日,Choerodon 猪齿鱼发布0.17版本,本次更新新增了代码质量图、项目群路线图、项目群公告板和自动化测试 TestNG + Selenium 框架等功能,欢迎各位更新体验。

  • 发布版本:0.17
  • 发布时间:2019 年 6 月 3 日
  • 更新范围:大规模敏捷、知识管理、敏捷管理、持续交付、测试管理以及微服务开发框架

下面就为大家带来详细的版本更新介绍。

新增功能

大规模敏捷

  • PM 可以在项目群路线图查看 3 个 PI 的 feature 待办事项。

  • 项目群成员可以通过公告板查看各个团队以及迭代之间的依赖关系。-

  • 项目群完成 PI 时,将自动完成 PI 下的 sprint,team 前端接受到提示。
  • 项目群-项目设置可以查看项目信息。

  • 项目群可以根据工作日历查看工作时间。
  • 项目群 feature 管理列表功能升级、可以进行高级搜索。
  • 特性查询模式下支持排序。
  • 项目群看板添加快速搜索。

敏捷管理

  • 用户可以在故事中直接创建缺陷。

持续交付

  • 开发流水线模块新增代码质量页面,支持查看应用在 SonarQube 中的检测结果与具体详情。

  • DevOps 报表中新增代码质量图,支持查看应用代码质量中 Bug、安全漏洞、代码异味、重复度与单测覆盖率的变化详情。

  • 项目设置模块新增通知设置的功能,支持为各个环境下的删除事件配置通知方式(邮件、站内信或短信)与通知对象。

  • 在通知设置中创建通知成功后,删除环境下的实例等资源时,需要输入通知得到的验证码进行删除操作的二次确认。

  • 项目设置模块中组件设置页面新增设置项目 Harbor 仓库类型的入口。
  • 部署流水线模块中配置映射部分,新增以 YMAL 格式进行创建与编辑。
  • 部署流水线模块状态为执行中的流水线详情中新增手动终止的按钮,项目所有者可以在此手动终止任何执行中的流水线。

测试管理

  • 自动化测试新增 TestNG + Selenium 框架。
  • 需求追踪性报表新增冲刺、版本字段展示、筛选。

微服务开发框架

  • 新增创建角色选择权限界面,权限返回信息以菜单分组。

  • 初始化菜单使用 excel 通过 sagaTask 初始化。
  • 项目群和项目禁用时,禁用对应的关系。
  • 请求 header 同时加入 Jwt_Token 和 Authorization,支持平滑升级。
  • asgard-service 通过 spring 提供的 DeferredResult 实现长轮询服务端推送消息。
  • 后端服务 choerodon-starter-mybatis-mapper 依赖 更换为 choerodon-starter-mybatis 依赖。

功能优化

敏捷管理

  • 问题关联关系展示关联的测试用例。
  • issue 导入模板增加模块、冲刺等字段。
  • issue 详情页面的宽窄样式优化。
  • 自定义字段优化相关优化。
  • 部分页面样式优化。
  • 部分报表优化。

持续交付

  • 优化了流水线详情中未执行任务的详情展示。
  • 优化了流水线详情内部署任务中实例的跳转功能。
  • 优化了流水线详情界面的 UI。
  • 优化了流水线中无环境权限的项目成员的权限问题。

微服务开发框架

  • 前端页面按照不同服务进行重新拆分。
  • 修改角色管理页面按角色进行筛选。
  • 修改应用管理及维护组合应用页面。
  • 修改项目管理页面风格。
  • 修改消息通知页面为右侧滑出展示。
  • 修改菜单结构。
  • gateway-helper 合并到 api-gateway。
  • 发送消息修改为优先根据设置的自定义发送类型发送。

缺陷修复

大规模敏捷

  • 修复史诗筛选的 PI 显示 BUG。
  • 修复 ART 列表时间显示 BUG。

敏捷管理

  • 修复史诗报告中不同维度下数据的展示。
  • 修复问题管理中根据名称搜索不准确的问题。
  • 修复 5.1 节假日调整问题。

持续交付

  • 修复了在开发控制台中能选择到应用市场导入的应用的问题。
  • 修复了创建流水线时人员查询重复的问题。
  • 修复了流水线中用户选择器的筛选问题。
  • 修复了流水线详情中点击展开按钮查看详情时全部展开的问题。
  • 修复了应用导出时部分应用获取 chart 包失败的问题。
  • 修复了从应用市场导入的应用分配权限报错的问题。
  • 修复了 gitops 执行 saga 事务实例偶尔会卡住的问题。
  • 修复了创建应用的 saga 事务处理逻辑中,偶现更新应用失败的问题。
  • 修复了 gitops 中对象的 annotation 没保留的问题。

删除

微服务开发框架

  • 分页查询移除 PageRequest,不再支持前端传字段自动排序。
  • 移除 gateway-helper,gateway-helper 不再进行更新。

社区参与

感谢以下这些朋友在社区论坛中提出反馈和意见,在 0.17 版本更新中作出突出贡献。

  • @lisen2023
  • @2865
  • @phoenix
  • @felix

更加详细的内容,请参阅Release Notes官网

欢迎各位朋友通过 Choerodon 的GitHub猪齿鱼社区进行反馈与贡献,帮助 Choerodon 猪齿鱼不断成长。Choerodon 会持续优化,敬请期待

欢迎加入 Choerodon 猪齿鱼社区,共同为企业数字化服务打造一个开放的生态平台。

· 13 分钟阅读

作者 | Rebecca Pruess

编译 | 毛智伟

随着 DevOps 理念的普及与扩散,大家经常会看到持续集成(Continuous Integration)与持续交付(Continuous Delivery)这样的字眼,而怎样使用与选择这些方法成了大多数 IT 团队必须面对的问题。在讨论更加深入地讨论问题之前,首先需要清楚这两者之间的主要区别是什么,以及用什么方法可以更好改善工作流程,从而在更短的时间内为目标用户提供更高质量的软件。

devops

持续集成(CI)和持续交付(CD)都体现了如今快节奏市场中的文化和发展原则,旨在缩短开发周期、提高软件交付效率以及实现全流程的自动化。同时,两者都有着共同的目标:让软件开发更少地依赖于手动执行的任务,在此基础上使得软件的发布更加频繁、更加安全可靠。由于有着相同的目标,因此持续集成和持续交付并非相互排斥的。只是它们的应用范围有所不同。

那下面就来看下 CI 与 CD 之间的联系与区别。

什么是持续集成

如上所述,CI 和 CD 是相互关联的。持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误。由此可见,CI 专注于定期地让开发人员构建小批量的代码。而对于更新或新增的代码,它们会被上传至统一的代码库,执行自动构建与自动化测试的步骤。 频繁地向主干提交代码,意味着可以针对整个软件执行所有的自动化测试,并且在应用或接口的某个部分出现问题时,及时收到告警信息。

由于合并问题能被及时发现,因此也能被及时解决。此外,由于测试过程采用的是自动化测试,因此最终的主干分支一直处于可发布的状态。而这对传统的瀑布式的开发流程来说就很棘手。遵循 CI 中定义的原则,有助于进一步提高代码的可测试性和可部署性。通过将代码保持在可部署状态,就能避免在项目后期才进行单独的测试和 Bug 的修复,由此使得开发人员避开了“集成地狱”。而这也是 Choerodon 猪齿鱼开发流水线模块的主要目的。

ci

什么是持续交付

持续集成包含了构建与自动化测试的阶段,而持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的“类生产环境”之中。持续交付优先于整个产品生命周期的软件部署,建立在高水平自动化持续集成之上。此外,持续交付同样遵循一个小型的构建周期,可以将一小批代码推送到多个环境:开发,测试或生产。

在此过程中,它结合了持续集成和持续部署的实践(即:让主干始终处于可部署状态)。而在 Choerodon 猪齿鱼平台中,当提交的代码完成以上步骤后,可以在“部署流水线-流水线管理”中创建对应的 CD 流水线将持续集成后产生的应用版本自动部署到对应的环境中去。此外,对于部署到正式环境的代码,可以在流水线中间添加一个人工卡点任务,只有通过人工审核后,才能执行后续的自动部署任务。

ci

理论上来说,CD 使得 IT 团队可以每天发布与更新应用程序,但大多数 IT 团队选择每月或每两个月发布更完整的更新。

持续集成与持续交付的区别

CI 和 CD 之间的区别在于使用的范围和主要的受益者。

(1)持续集成

持续集成对于加快编码和构建阶段的软件交付过程至关重要。因此,它的目标对象主要是开发人员,特别是那些处在复杂组织架构中的开发人员。通过自动构建和测试的流程,将对软件做的所有更改都集成到统一的代码库中,而无需进行手动任务。此外,由于 CI 是一个持续的过程,因此开发人员可以即时得到问题的反馈。他们可以实时获取到相关错误的信息,以便快速地定位与解决问题。显然这个过程可以大大地提高开发人员以及整个 IT 团队的工作效率。

(2)持续交付

持续交付涵盖了软件交付生命周期的绝大部分,能为目标用户和客户带来重大利益。CD 中包含了自动构建,打包,部署与测试的流程,以此来减少手动任务并加快软件交付速度。小批量的代码成功完成整个流程的每个阶段后,目标用户或客户便能在类生产环境中进行验收。因此目标用户可以在几天或几周内就收到修复后的功能与新增的功能,而无需等待数月后才更新。

CD 的部署频率也加快了整个流程中的反馈循环。最新版本真的解决了预期的问题吗?是否满足了用户的需求?在此用户就可以快速地验收并作出判断,而 IT 团队也可以在问题影响到开发周期之前就解决反馈的问题。持续的反馈循环使得用户与 IT 团队更紧密地合作,以确保能准确的理解与满足他们的需求。整个交付过程进度可视化,方便团队人员与客户了解项目的进度。

在当前快节奏的市场中,这无疑是一个重大的优势。当您将软件更快地推向市场时,您将获得更大的竞争优势。

CI 或 CD 适合您的业务场景吗

持续集成可确保代码库中始终保持最新的代码,同时可以快速集成来自多个开发人员的代码,并确保这些代码可在多个环境中协同工作。它通常有助于减少错误并通过自动化流程来减少手动任务。CI 可以实现代码的自动构建与测试,减少开发中的 Bug。因此,CI 适用于那些过度依赖手动任务和复杂构建过程的企业。

持续交付适用于需要缩短开发周期,更快地为目标用户提供软件的企业。CD 降低了部署新软件或升级已有软件的难度,且实现了全流程的自动化,因此您的团队无需手动执行复杂繁琐的任务,从而加快反馈速度,来确保您增加的功能真正地满足用户的需求。

总而言之,CI 和 CD 是相互补充的。CI 的统一代码库和自动化测试的方法可用于支持 CD 中更大规模的自动化和更频繁的部署。因此将 CI 和 CD 结合到您开发与交付的流程中,会使您的 IT 团队更加敏捷,更加快速地开发。

目前,大多数 CI / CD 的工具采用的方法都大同小异。 而一般的 DevOps 工具通常都会支持 CI 和 CD 方法,相应地还会提供相关的自动化测试框架。Choerodon 猪齿鱼平台中的 DevOps 模块便是结合了 CI 与 CD 的方法,并在此基础上实现了测试与部署的自动化。用户需要根据自己的实质需求来创建 CD 流水线,以此来实现不同环境不同版本类型的自动化部署;当然,您还可以在其中设置人工卡点任务,使得 CD 流水线随时处于人工的监控之下。

此外,也有不少人认为 CI 是 CD 的前提与基础,没有 CI 就不能实现 CD。这种说法也是比较流行的,其思路如下图。因此,不管是哪种说法,CI 与 CD 都是 DevOps 工具中不可或缺的理念与方法。

Devops Flow

原文地址: https://dzone.com/articles/continuous-integration-vs-continuous-delivery

更多 Choerodon 猪齿鱼持续交付相关文章 ▼

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

· 4 分钟阅读

什么是猪齿鱼

Choerodon 猪齿鱼 是一个全场景效能平台,是基于 Kubernetes,Istio,knative,Gitlab,Spring Cloud 来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps 等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

公开课有什么?

本次使用培训公开课直播将讲解 Choerodon 猪齿鱼的几大核心功能的使用,详情如下:

5 月 27 日

Choerodon 猪齿鱼敏捷管理

  1. 敏捷理论的概要介绍
  2. 需求的收集及记录
  3. 迭代的规划
  4. 迭代的执行
  5. 数据查看及分析

Choerodon 猪齿鱼大规模敏捷

  1. 项目群管理的使用场景
  2. 什么是敏捷发布火车
  3. PI 的规划以及目标
  4. 项目群与各团队之间的项目协作

5 月 28 日

Choerodon 猪齿鱼持续交付

  1. Choerodon 猪齿鱼 DevOps 方法讲解
  2. Choerodon 猪齿鱼 DevOps 架构讲解
  3. Choerodon 猪齿鱼 DevOps 功能演示

5 月 29 日

Choerodon 猪齿鱼测试管理

  1. 测试用例维护
  2. 测试计划
  3. 执行测试
  4. 测试报表分析
  5. 自动化测试

三天三节课,各大模块**研发工程师和产品经理**亲自讲解。

直播平台

IT 大咖说(搜索 Choerodon 猪齿鱼收藏直播间)

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

· 11 分钟阅读

应用程序日志是由软件应用程序记录的事件文件, 它一般包含错误,信息事件和警告。一个良好的日志系统有助于快速发现问题,定位问题,同时也为业务分析起到一定的作用。

传统ELK系统

ELK系统是目前比较流行的日志解决方案,由Elasticsearch、Logstash、Kibana组成,目前三个组件都归属于Elastic。

Elasticsearch是一个基于Lucene库的搜索引擎。它提供了一个分布式、支持多租户的全文搜索引擎,具有HTTP Web接口和无模式JSON文档。Elasticsearch是用Java开发的,并在Apache许可证下作为开源软件发布。

自2010年发布以来,Elasticsearch已迅速成为最受欢迎的搜索引擎,常用于日志分析,全文搜索和业务分析等业务场景。

![](./img/journal/image (6).png)

Logstash 将日志收集后发送到Elasticsearch中进行存储,用户访问Kibana提供的UI界面查询数据。

Choerodon中的日志系统

总览

和ELK类似,Choerodon选用了Elasticsearch存储日志数据,并由Kibana展示数据。Choerodon平台运行在Kubernetes平台之上,同时也管理多个Kubernetes集群,为了让日志系统尽可能的不影响业务系统,Choerodon使用了比Logstash更轻量的由C语言编写的fluent bit替代采集端工具Logstash。fluent bit通过Deamonset的方式运行在Kubernetes集群中的每一个可调度的节点上,实时采集日志,发送到Elasticsearch中,一般情况下,从日志产生到Kibana中可以查看到的延迟不超过1秒钟。精简结构图如下:

![](./img/journal/image (7).png)

先看一下查看界面:

![](./img/journal/image (8).png)

通过搜索关键字error查询含有该关键字的日志,界面显示最近15分钟gateway-helper服务出现了三次error的日志信息,列表中为该日志的缩略信息,可以点击日志前面的小箭头展开查看完整的信息。

![](./img/journal/image (9).png)

展开之后就可以看到更加详细的信息了。

PS:多行展示官方的fluent bit截止目前暂未良好的支持docker中的json-file日志,建议使用Choerodon定制fluent bit。

Fluent bit vs Fluentd

Fluentd和Fluent Bit项目均由Treasure Data创建和赞助,旨在解决日志的收集,处理和交付问题。

两个项目都有很多相似之处,Fluent Bit完全基于Fluentd架构和一般设计的设计和经验。选择使用哪一个取决于最终需求,从架构角度可以考虑:

  • Fluentd是日志收集器,处理器和聚合器,使用Ruby和C构建。
  • Fluent Bit是一个日志收集器和处理器,它没有像Fluentd一样强大的聚合功能。在Choerodon日志方案聚合功能由Elasticsearch提供。Fluent bit一般情况下占用内存要仅为fluentd十分之一以下。

类似于Fluent bit的组件还有很多如Filebeat等,Choerodon也在关注各主流组件的更新,选择最合适的日志采集端工具。

如何自动收集日志

一般在采集日志的时候,为了更容易分析日志,需要将日志进行解析。下面的这个图中将Java应用的一条日志解析为level,class,processid和msg四个部分:

![](./img/journal/image (10).png)

解析日志需要指定解析规则,Choerodon部署界面可以为应用配置解析规则,当配置了解析规则后即表示该应用的日志需要按照配置的规则收集,部署界面如下图所示:

![](./img/journal/image (11).png)

通过mysql这个解析规则解析该应用的日志,目前Choerodon日志解决方案中默认提供了docker、mysql、tomcat、springboot和nginx的日志解析规则,如果你认为需要添加其他通用的日志解析规则欢迎到Choerodon社区中建议。

在Fluent-bit中可以配置通配符"*”来收集匹配规则的日志,但是很多时候开发者希望在部署应用时指定是否收集日志。在Choerodon平台中,应用是运行在Kubernetes平台之上的,所以开发者可以通过给应用的部署集添加标签来表示需不要收集日志,再通过一个程序去读取标签的内容,自动修改Fluent-bit的配置就可以随心的控制是否需要收集日志了。如果需要默认收集所有应用的日志,排除部分日志可以使用Fluent-bit提供的 fluentbit.io/exclude注解。

在日志中添加集群相关的信息

Choerodon的服务运行在Kubernetes集群中,如果能够在查看日志的时候也能看到日志来自哪个服务器,属于哪个Pod就能够更快的定位和查找问题。

Fluent bit提供了Kubernetes的filter,通过赋予Fluent bit查询权限,它就能够自动的为每条日志附加集群的相关信息。

![](./img/journal/image (12).png)

如上图所示,你可以看到每一条日志来源的主机,命名空间,所属Pod名称等信息,大大提高了开发者定位的能力。

如何告警

收集日志之后开发者需要对某个关键字出现的次数进行告警,如Exception这个关键字在某服务中一分钟出现了5次以上,需要将这个消息通知给特定的人员。

在这之前大家先来了解一下Choerodon中的监控方案:

![](./img/journal/image (13).png)

应用监控数据经Prometheus采集处理之后展示在Grafana中,告警信息通过Alertmanager发送给用户。因为在监控方案中已经有可用的告警机制,开发者只需要将日志系统中的内容转换为Prometheus可以采集的指标数据即可使用监控方案中的告警机制。

Elastalert是用Python编写的Elasticsearch告警工具,通过配置一定时间间隔查询elasticsearch数据库,对比预设规则达到告警的目的,Choerodon可以通过简单的改造elastalert实现将elastalert查询的结果转换为Prometheus的数据格式供Prometheus拉取。改造步骤分为以下几个部分:

  1. 引入prometheusSDK:prometheus提供了Python的SDK,简单的引入之后应用就具有了可以被监控的特性,可以选择监听指定端口已提供监控数据。

  2. 埋点:将更新监控数据的操作置于elastalert每次执行查询完成后已更新监控数据即可。

目前Choerodon正在用Golang开发新的日志监控工具,得益于Golang的特性,新的日志监控工具将以更低的内存消耗,更低的cpu占用和更稳定的运行状态为日志监控提供支持。

使用Choerodon认证登录Kibana

如上所示,Kibana作为日志查看界面,如果使用社区版Kibana是没有权限校验的,会存在一定风险,希望授权用户才能访问日志查询界面。为此Choerodon设计开发了一个认证代理服务,将无权限控制的Kibana放置于认证代理的后端,只有通过了认证,才能访问到Kibana的界面。如下图所示:

![](./img/journal/image (14).png)

效果图:

现在,你已经了解Choerodon的日志方案,接下来就可以跟随着Choerodon官网部署尝试一下吧。

参考文献:

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

· 13 分钟阅读

Choerodon作为多云管理平台,可以通过LDAP的方式对接企业已有的应用,通过同步用户到Choerodon平台,使企业用户无需注册就可使用LDAP的账户和密码登录到Choerodon平台,实现 DevOps 开发运维一体化和敏捷管理的等目标,极大地降低了企业用户迁移负担。

本文将从LDAP的概念,如何使用Choerodon LDAP以及配置定时任务三个方面进行介绍。

什么是LDAP

LDAP是轻量级目录访问协议(Lightweight Directory Access Protocol)的缩写,是一个开放的,中立的,工业标准的应用协议,用于与目录服务进行交互。LDAP有许多种实现,比如Open LDAP和微软的Active Directory等,类似于关系型数据库的多种不同的实现,如oracle和mysql等。

LDAP基于TCP/IP协议,使用Client/Server架构,允许客户端在目录服务器中执行各种操作,包括存储和检索数据,搜索与给定标准集匹配的数据,对客户端进行身份验证等。LDAP的标准TCP端口对于未加密的通信是389,对于通过TLS加密的通道的LDAP是636,这里可以类比HTTP协议默认端口为80,HTTPS协议默认端口为443。

LDAP目录使用有层次的、树形结构存储数据,具有优异的查询,浏览和搜索性能,但写入性能差,没有事务处理和回滚等功能,不适合频繁修改数据。通常用于存储公司员工信息,用户使用同一个账户和密码就可以登录到多个不同的服务,也可以存储公用证书和安全密钥,公司物理设备信息等。

基本概念

Directory Servers

目录服务器是一种存储树形条目信息的网络数据库,与关系型数据库存储行和列的关系信息不同,可以被认为一种NoSQL数据库。

Entries

LDAP entry(LDAP条目)是有关实体的信息集合,每个条目由下面三部分组成:DN,属性集合(attributes)和对象类集合(object class)。

DNs and RDNs

DN是distinguished name的缩写,是entry的唯一标识,同时记录了entry所在的目录树层级位,类似于文件系统的上下文路径。

一个DN由零个或多个相对可分辨的名称或者RDN组成。每个RDN由一个或者多个属性-值组成(通常是一个)。例如uid=superlee,dc=choerodon,dc=io这个DN,由3个RDN组成,RDN的顺序指定了DIT(directory information tree)中相关条目的位置,从左到右以降序表示层级结构,即父目录在偏右侧,上述DN的父目录的DN为ou=choerodon,ou=io,uid是RDN的属性,superlee是RDN的值。

Root DSE是一个长度为0的字符串DN的特殊条目,每一个LDAP server 必须要有一个这样公开的特殊条目。

Attributes

Attributes用于保存条目的数据。一个条目可以有多个attribute,每一个attribute都有一个attribute type (属性类型),零个或多个attribute options(属性选项)以及一组包含实际数据的值。

属性类型指定LDAP client和server应该如何处理该属性,必须包含对象标识符(OID)和零个或多个名称。

属性选项不常用,但是可以提供一些元数据,如对该属性的值进行多语言处理。

如图所示,该entry包含了多个attribute。

Object Classes

对象类标记条目的类型,每个条目有一个结构对象类,指明条目所代表的对象类型(person/group/device等),还有零个或多个辅助对象类,提供其他特征。

Object Identifiers (OIDs)

对象标识符,用于唯一标识LDAP协议中的各种元素,OID由一系列由句点分隔的数字组成(例如,“1.2.840.113556.1.4.473”是表示服务器端排序请求控件的OID)。

可以使用ldapsearch命令查询LDAP server是否支持分页查询。

ldapsearch -H ldap://ldap.server.address:389 -x -D "uid=superlee,dc=choerodon,dc=io" -W -b "" -s base -a always "(objectClass=*)

如果返回值里包含1.2.840.113556.1.4.473,那么服务器就是支持分页查询的。

其他术语

  • base DN: 基准DN,通常指一个属性结构的顶部,如下的树形结构的base DN就是dc=gp,dc=gl,dc=google,dc=com

  • DIT: directory information tree
  • entryUUID: 包含DIT条目的通用唯一ID(UUID)的属性。
  • LDIF: LDAP数据交换格式。IETF术语,用于加载(导入)和保存(导出)条目到LDAP启用目录的文本格式。用于数据的导入导出,每行都是“属性: 值”对,见openldap ldif格式示例(http://uee.me/aVvkE)
  • dc: domain component,通常指域名的每个组件,如www.baidu.com可以被写成dc=www,dc=baidu,dc=com
  • cn: common name,被广泛用作命名某些“东西”或真实世界实体的属性。
  • ou: organizational unit name,表明用户所属的组织单元,属于多个组织使用逗号隔开。
  • l: locality name,局部名,地方名
  • st: state or province name,州或者省份名称
  • o: organizational name,组织名
  • c: country name,国家名
  • street: street name,街道名
  • uid: user id,用户id

Choerodon LDAP使用

详情可阅读《Choerodon LDAP文档》

这里做一些补充说明。

Choerodon的LDAP在组织层级,即每个组织都有各自的LDAP配置,配置好LDAP后即可同步到当前组织下,用户登录的时候根据登录名查询对应的组织,然后找到对应的LDAP server去认证,认证通过则登录成功,否则则登录失败。

如果组织下的LDAP已经被停用,则该组织下的所有LDAP用户都不能登录。

Choerodon只支持可以分页查询的LDAP server。

  • 2: 主机名,即ldap server的地址,必须以ldap://或者ldaps://开头。
  • 4: 这个值是每次分页查询用户的数量以及发送saga事件的用户数量。
  • 5: 查询和连接LDAP server的超时时间,单位为秒。

注意: 管理员登录账户和密码,要有在base DN上的登录权限,否则测试连接会报登录失败。

  • 1: 用户对象类,一般设置为person,用于检索符合这个类型的条目。支持输入多个object class,使用逗号分隔。
  • 2: 读取entry的该属性设置到iam_user表的login_name字段,作为登录名。
  • 6: uuid,LDAP对象的唯一标识,大多数是entryUUID属性,Microsoft Active Directory可能是objectGUID属性,如果您的的ldap服务器确实不支持uuid,使用能唯一标识对象的字段即可,比如uid或者entryDN。记录部分用户同步失败的uuid,方便到LDAP server查询。
  • 7: 额外的过滤条件用于同步用户,允许为空,表达式必须以“(”开始,以“)”结束,语法参考ldap search syntax(http://uee.me/aVvmj)。

注意: 测试连接里的属性匹配,抓取了base DN下的100个满足已经设置的用户对象类和自定义筛选条件的条目,然后去校验设置好的loginName,email等 属性是否存在,如果不存在该属性名就返回不匹配。

Choerodon LDAP定时任务配置

Choerodon 支持配置LDAP同步用户和禁用用户定时任务,定时任务配置文档。

组织层设置同步定时任务

首先进入组织层的任务明细界面

然后在当前界面点击创建任务按钮

任务支持简单任务和cron表达式任务,这里以简单任务作实例,每天同步一次,执行30次。

超时策略:

  • 阻塞: 下次触发时间若上次触发任务未完成,则暂停定时任务,任务不再被执行。
  • 串行: 下次触发时间若上次触发任务未完成,两次任务可按照触发时间依次被执行。
  • 并行: 下次触发时间若上次触发任务未完成,两次任务可以同时被执行。

点击下一步选择iam-service,Choerodon有两个内置的定时任务,同步定时任务和禁用用户定时任务。禁用用户定时需要设置filterStr,用来筛选需要禁用的用户。这个筛选表达式必须以'('开始,以')'结束,语法参考ldap search syntax。

点击下一步选择通知对象,之后点下一步确认信息后创建即可。

全局层设置同步定时任务

首先使用具有site层权限的账户登录,然后按如下顺序点击菜单,进入任务明细界面。

然后在当前界面点击创建任务按钮,这里和组织层的操作一致。

在配置执行程序时,Choerodon内置了两个默认的LDAP相关的全局层任务。其中同步用户需要设置组织code参数,表明同步该组织下的用户,过滤停用用户需要设置组织code和筛选停用用户的条件。之后选择下一步和需要通知的对象确认即可。

关于猪齿鱼

Choerodon 猪齿鱼是一个全场景效能平台,基于 Kubernetes 的容器编排和管理能力,整合 DevOps 工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台,同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

· 12 分钟阅读

Choerodon猪齿鱼全场景效能平台,是基于Kubernetes,Istio,knative,Gitlab,Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。

2019年5月8日,Choerodon猪齿鱼发布0.16版本,本次更新主要新增了项目群管理、自定义部署流水线等功能,欢迎各位更新体验。

  • 发布版本:0.16
  • 发布时间:2019年5月8日
  • 功能范围:知识管理、敏捷管理、持续交付、测试管理以及微服务开发框架

下面就为大家带来详细的版本更新介绍。

新增模块

大规模敏捷管理

猪齿鱼的大规模敏捷是基于规模化敏捷框架(SAFe 4.0),主要是为多个团队的产品级敏捷管理提供解决方案,促进众多敏捷团队之间的协调一致、协作和交付。有助于企业在最短、稳定的前置时间内解决开发与交付企业级软件和系统中遇到的巨大挑战。

本版本包含以下功能:

  • 新增项目群ART设置,支持创建、修改、开启、停用ART,以及ART下的PI列表的展示。这是项目所有者对大规模敏捷项目的一些设置,包括敏捷发布火车设置、项目编码以及工作日历设置。

  • 新增项目群特性列表,特性列表展示了一个项目群中规划的特性,包括计划模式和查询两种模式,并且支持创建特性。

  • 新增项目群看板,支持特性的移动、展示等。不同于团队的看板,关注的是一个冲刺的用户故事,项目群看板则关注的是全部的特性。

  • 新增项目群看板的配置,包括列与状态的配置。

  • 新增项目群项目设置,支持修改项目编码。
  • 新增项目群ART日历,支持查看正在进行中的ART的PI规划以及PI下的冲刺规划。ART日历展示的当前进行中的这列火车的节奏,通过日历可以看到当前ART处于哪个PI,团队处于哪个迭代等信息。

  • 新增项目群PI目标,包括列表和卡片两种模式,支持创建、修改、删除、查询PI目标。
  • 新增项目群的team中的story可以关联待处理或处理中状态的feature。
  • 项目群中开启PI后,为项目群中的每个team同步生成sprint,同时不允许删除、创建新的sprint。

新增功能

敏捷管理

  • 创建问题/编辑问题页面支持自定义字段的应用。

持续交付

  • 部署流水线模块新增流水线的功能,支持在流水线中创建多个阶段,且每个阶段中可添加多个任务,包括自动部署任务与人工卡点任务。

  • 部署流水线模块新增流水线执行总览页面,支持查看流水线的执行情况、流程详情以及审批历史。

  • 部署流水线模块新增部署配置页面,支持在此创建部署配置用于流水线中添加自动部署任务时选择。

  • 平台中新增CLI工具,支持使用命令行的方式来执行平台中的页面操作。
  • 创建网络页面,网络配置类型为NodePort时,新增了TCP/UDP协议的选择框。

测试管理

  • 新增测试计划中对循环或阶段克隆批量操作功能。。

微服务开发框架

  • 新增项目群管理相关功能,通过项目群管理项目群下的所有子项目,创建项目时可以选择项目分类为项目群,并且可以在项目群下添加子项目。

  • 组织管理查询新增注册时间字段。

功能优化

知识管理

  • 优化删除收藏夹后续动作,当要删除收藏夹时,可以选择将收藏的页面移动到其他收藏夹。
  • 空间的最近空间活动改成异步加载。
  • 优化操作体验,wiki空间管理,处理失效的地址失效,不能点击。
  • 优化从猪齿鱼的项目链接到空间无页面显示。
  • 优化操作体验,评论为空,点击“添加评论”后应该给相应的提示。

敏捷管理

  • 项目成员可以在项目首页查看未分配的任务,支持分页。
  • 当一个故事下的子任务被移动到下一个冲刺中,会记住之前的状态。
  • 优化部分页面样式。
  • 优化部分报表。

持续交付

  • 优化了Values组件的diff效果,支持切换编辑器模式来对比查看代码行的 增、删、改。
  • 优化了应用与环境权限分配模块,被分配权限的项目成员在 gitlab 中的角色统一改为developer。
  • 优化了平台里执行创建操作时出现熔断后的报错提示。
  • 优化了组织层的集群列表的显示。
  • 优化了组织层集群的删除逻辑,仅能删除没有关联环境的集群。
  • 优化了实例中操作日志页面的显示。

测试管理

  • 优化测试计划、测试执行性能问题。
  • 优化测试体验,创建测试循环中,时间选择器优化。
  • 优化测试体验,测试计划时间条可以前后拖动。
  • 优化测试体验,测试计划中编辑阶段允许更改关联的文件夹。
  • 优化测试体验,测试缺陷报表排序,根据创建时间由近到远。
  • 优化测试体验,测试执行中点击用例详情中的编号到用例时重新打开一个窗口。
  • 优化测试体验,测试报表、测试用例中搜索编号允许带前缀。

微服务开发框架

  • 修改角色分配查询用户更新逻辑,同组织下模糊查询,不同组织精确查询。
  • 修改打包时进度日常输出。
  • 修改对choerodon-ui的版本依赖规则。

缺陷修复

知识管理

  • 修复旧空间为异步加载。

敏捷管理

  • 修复史诗报告中不同维度下数据的展示。
  • 修复问题管理中根据名称搜索不准确的问题。
  • 修复5.1节假日调整问题。

持续交付

  • 修复了删除部署错误的网络时会报错的问题。
  • 修复了yaml编辑器错误提示的显示问题。
  • 修复了自动部署同一版本部署替换至多实例时失败的问题。
  • 修复了自动部署任务中手动输入的版本类型无法触发任务的问题。
  • 修复了在敏捷管理中创建任务时查询tag失败的问题。
  • 修复了在组件设置中创建harbor仓库失败的问题。
  • 修复了loadbalancer类型的网络外部ip没有返回的问题。
  • 修复了创建应用时编码中间有两个中划线会创建失败的问题。
  • 修复了部署应用时未作修改便提交导致的问题。
  • 修复了各服务配置configMap没有回扫成功的问题。

测试管理

  • 修复树状图空数据报错。
  • 修复测试执行进度条计数错误。

微服务开发框架

  • 修复ldap同步历史显示信息异常的问题,不显示当前正在同步的同步记录信息。
  • 修复ldap分页同步用户可能导致死循环的问题。
  • 修复导入用户异常的问题。
  • 修复创建应用发送saga,enabled字段为空的问题。
  • 修复实例详情拿不到配置信息的问题。
  • 修复菜单导出问题。
  • 修复ie 11 下样式显示问题。
  • 修复前端在CI build阶段卡住的问题。

删除

持续交付

  • 移除了0.15版本中的自动部署页面,并将其内置于流水线中添加任务部分。

社区参与

感谢以下这些朋友在社区论坛中提出反馈和意见,在0.16版本更新中作出突出贡献。

  • @codercyj
  • @phoenix
  • @8192
  • @niu810
  • @felix

更加详细的内容,请参阅Release Notes官网

欢迎通过猪齿鱼的GitHub猪齿鱼社区进行反馈与贡献,帮助Choerodon猪齿鱼不断成长,猪齿鱼将持续迭代优化,敬请期待。