Choerodon猪齿鱼

在SAFe中，每个PI都需要交付一定的价值。PI的执行过程中，各个敏捷团队致力于实现PI计划会中承诺的PI目标。PI过程中的每个敏捷迭代都很重要，每个迭代都承担了和团队相符的工作量，敏捷团队大多数时间都在“低头干活”，并且将精力聚焦在最近要交付的价值上。每个迭代、每个PI都有一种时间紧迫性。由于这种紧迫性，可能会存在一种风险，ART（敏捷发布火车）没有预留的时间用来调整、创新学习、计划，那些时间紧迫的任务的优先级将超过任何活动。为了解决这个问题，SAFe提供了专门的Innovation and Planning（IP） 迭代。下文将为您详细介绍IP迭代。 什么是IP迭代 IP迭代是固定在PI末，持续一周的特殊迭代，它为团队提供了一个有规律、有节奏的时间段，让团队可以有机会开展一些在持续不断的增量价值发布的环境中很难进行的工作。这些工作可以包括如下内容： 创新和探索； 编写发布文档、产品手册； 黑客马拉松；（下文有解释） 检视和调整工作坊，包括最终PI系统演示； 项目群和团队待办事项列表梳理； 处理技术基础设施、工具和其他系统障碍； 促进持续学习； PI计划。 同时，IP迭代还有其他重要的作用，比如提供为满足Pl目标实现所需要的缓冲时间，以及增强发布的可预测性。从敏捷发布火车的执行可以看出，通过有规律地对团队进行“重新充电和工具锐化”，整个团队的有效性、速度

课程说明 本课程介绍如何利用Buildrun低代码平台构建数据模型，为页面设计提供数据来源。涉及的主要内容有： 低代码应用服务 数据模型 创建静态值列表（选项集） 创建业务对象 定义业务对象的属性 完成V1.0业务对象的定义 课程内容 1. 低代码应用服务 低代码应用服务是Buildrun平台中的一种通过可视化构建的应用服务类型，底层基于微服务技术体系实现，构建的低代码应用加上Buildrun多云应用引擎(BrAppEngine)构成了完整的云原生应用体系。 登录Buildrun平台后，选择顶端菜单“ 项目 ”进入项目列表界面，点击我们创建的“ Br一站式物联网应用平台项目 ”的“ 物联网低代码服务详情 ”，在服务窗口中点击“ 进入设计器 ”按钮进入应用设计器；也可以进入“ 项目视图空间 ”中，选择“ 开发->应用服务 ”进入应用服务界面，点击应用服务的“ 进入设计器 ”链接进入应用设计器。 2. 数据模型 根据前面课程的准备和BrIoT应用平台的需求，我们规划了v1.0版本中主要实现产品和设备的新增、修改和查看功能，因此需要定义产品和设备两个业务对象来存储相关的信息，下面是第一版本的业务对象设计。 业务对象 是将信息保留在数据库中并实现数据库模型的元素，可以将它们视为数据库表或视图。 业务对象是通过存储与之相关的 实体属性 定义的，实体属性的示例包括：名称，地址，邮政编码，城市等

课程说明 Buildrun企业级低代码开发平台通过 “项目视图空间” 来管理从创意、需求梳理、系统设计、应用构建、一键式发布、应用管理到用户反馈的完整应用生命周期的管理。 “项目视图空间” 是整个应用生命周期管理的工作空间，是应用设计、构建、运行和管理各环节相关团队共同沟通协作的单一视图，也是应用团队和最终用户沟通协作的单一视图。 本课程主要描述以下内容来帮助理解和准备低代码应用开发环境： 企业组织、项目和应用服务的关系 如何创建项目和低代码服务？ 熟悉Buildrun企业级低代码平台的 “项目视图空间” 课程内容 1. 企业组织、项目和应用服务的关系 Buildrun平台是多租户架构设计，每个租户是一个独立的组织，在组织中完成所有应用生命周期管理的活动。 2. 创建项目和低代码服务 登录Buildrun平台后，选择顶端菜单“ 项目 ”进入项目列表界面，点击右上角的“ 创建低代码服务 ”按钮弹出创建界面，输入低代码服务信息和创建新的项目。 输入低代码服务信息： 服务编码 ： briotsrv 服务名称 ： 物联网低代码服务 服务简码 ： briotsrv 创建一个新的项目，输入项目信息： 项目名称 ： Br一站式物联网应用平台项目 项目编码 ： briot 3. “项目视图空间” 从项目列表中选择刚创建的 “Br一站式物联网应用平台项目” 进入项目视图空间。

3 月，跳不动了？>>> Prometheus 是 Kubernetes 中默认的监控方案，它专注于告警和收集存储最近的监控指标。但在一定的集群规模下，Prometheus 也暴露出一些问题。例如：如何以经济可靠的方式存储 PB 级别的历史数据，并且不牺牲查询时间？如何通过单一的查询接口访问到不同 Prometheus 服务器上的所有指标数据？能否以某种方式合并采集到的重复数据？针对以上的这些问题， Thanos 提供了高可用的的解决方案，并且它有着不受限制的数据存储能力。 Thanos Thanos 基于 Prometheus。当我们以不同方式使用 Thanos 时，或多或少都会用到 Prometheus 功能，但是 Prometheus 始终是指标收集和使用本地数据进行预警功能的基础。 Thanos 使用 Prometheus 存储格式，把历史数据以相对高性价比的方式保存在对象存储里，同时兼有较快的查询速度。此外，它还能对你所有的 Prometheus 提供全局查询视图。 依据 KISS 原则和 Unix 哲学，Thanos 划分如下特定功能的组件。 边车组件（Sidecar）：连接Prometheus，并把Prometheus暴露给查询网关（Querier/Query），以供实时查询，并且可以上传Prometheus数据给云存储，以供长期保存； 查询网关（Querier

某厂面试归来，发现自己落伍了！>>> Choerodon 开源多云应用敏捷全链路技术平台 ，是基于开源技术Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。 微服务开发框架升级 <blockquote class="warning"> 开始进行升级部署前请先备份好数据库。 请按以下顺序依次进行升级部署，请不要随意调整升级顺序。升级后可能数据库结构会发生改变，故不能进行版本回退。文档升级命令中的RELEASE NAME是在基于分步安装文档之上编写的，若你在安装时指定了其他RELEASE NAME，请以你安装时指定的RELEASE NAME为准。一键部署安装的请执行helm list命令查看RELEASE NAME。 </blockquote> 添加Choerodon Chart仓库 helm repo add c7n [https://openchart.choerodon.com.cn/choerodon/c7n/](https://openchart.choerodon.com.cn/choerodon/c7n/) helm repo

本文是敏捷管理系列的第一篇，将介绍敏捷中重要的需求管理，涉及需求的获取和管理，以及后续规划问题。 ▌ 主要内容： 瀑布流开发模式弊端 敏捷需求管理 如何获取需求 如何管理需求 史诗 用户故事 如何编写用户故事 如何规划需求——故事地图 总结 瀑布流开发模式弊端 在介绍敏捷之前先介绍一下 瀑布流模式 ，这是产品开发中非常常见的一种管理模式，它 以文档为驱动 ，在整个开发过程中，开发人员根据需求文档进行开发。所以在项目初期，确定需求和文档至关重要，通常在项目初期整个项目和产品便已经有了较为明确的雏形，项目成员需要严格按照需求文档和项目计划完成各自需要完成的工作。 由于在开发的中后期才会看到软件原型，早期只能通过文档来了解系统的模样，因此在一定的阶段，需求文档看起来会比产品实际的代码要重要。 这样的需求管理方式在传统软件系统管理中的优势在于可以在项目初期确定开发内容，更便于确定产品范围、人天预估、难度确认等，可大大减少项目失败风险，同时项目成员也能通过详尽的文档来确认自己的职责和范围。但是这种管理方式在日新月异的产品开发中显得越来越笨重，在实践的过程中产生了以下难以解决的冲突和问题，比如： 需求变更 ：需求变更是软件研发中经常遇到的一种情况，而在瀑布流的方式中，软件开发的后一阶段都是在前一阶段交付后才开始实施，流程多、周期长，这样的特点导致瀑布流在应对需求变更时需要付出很大的代价。

在敏捷开发中，大家经常会提到看板（kanban）这个名词，故名思义就是可视化的板。看板作为一个敏捷方法，与其他方法相比具有更强的可实施性，也更易让团队理解和执行。 下面将结合猪齿鱼团队的敏捷故事，给大家讲述下如何来使用看板，以及Choerodon猪齿鱼敏捷管理又是怎么辅助项目成员落地看板方法的。 第一原则：可视化 Choerodon猪齿鱼还没有发布第一个版本时，猪齿鱼的总设计师已经非常确定团队一定要使用敏捷的方式，去做一个敏捷开发工具来帮助企业提升系统交付的价值。 在猪齿鱼开发前期，团队需要去整理需求、收集需求、排列哪个故事先做哪个故事后做。那时候整个猪齿鱼开发团队被分成不同的敏捷小组，在办公室摆了4、5块白板。大家对照着看板方法中的图片模样，依葫芦画瓢地在看板上用线条进行分割，绘制出列和泳道，并买来各种颜色的便利贴和磁贴，猪齿鱼各个敏捷开发小组就这样用起来了看板。 首先需要让任务在板上呈现出来。 团队定好一个开发周期时，产品负责人（PO）会将这个周期内的所有需求都整理出并分别写在一张张大号便利贴上，按照优先级高低将卡片从上到下依次放在story这一列，剩下的故事卡片继续留在backlog这列里，直到有故事（卡片）做完再去backlog中将优先级最高的移动到story这列进行开发。团队根据故事的描述、对象和目的等信息将其拆分成一个个的开发任务，写在小号卡片上贴在doing状态列中

“它由Product backlog开始，经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事（story）形成迭代的sprint backlog（一个sprint一般为1个月）。在sprint中会进行每日站会，迭代结束时会进行演示和回顾会议。” 了解敏捷的朋友都知道backlog和spring是待办事项和冲刺的意思，但在使用Choerodon实践敏捷开发的时候这些敏捷术语对应的系统功能是哪些呢？为了解决大家在使用Choerodon时的困扰，整理了以下Choerodon功能与敏捷术语的对应表，以便大家进一步了解Choerodon的具体功能。 功能 敏捷术语 说明 问题 史诗(Epic) 非常大型的故事，可以横跨多个迭代周期。史诗故事在战术层面上使用前必须分解为一个个相关的用户故事。 故事（Story） 用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：1. 角色：谁要使用这个功能。2. 活动：需要完成什么样的功能。3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。 任务（Task） 是完成需求的过程性的工作。在迭代计划会议中，将纳入迭代的Story指派给具体成员，并分解成一个或多个Task，填写“预计工时”。 子任务 子任务通常是故事的具体拆分，拆分出的子任务将交给具体的开发、业务等人员处理，属于具体的任务交付

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者：Choerodon猪齿鱼社区 钟梓凌&黄显东 Kubernetes作为一个容器编排调度引擎，资源调度是它的最基本也是最重要的功能。当开发者部署一个应用时它运行在哪个节点？这个节点满不满足开发的运行要求？Kubernetes又是如何进行资源调度的呢？ ▌通过本文可了解到以下信息： 资源请求及限制对pod调度的影响 查看调度事件events 了解label选择器对pod调度的影响 了解节点亲和性和Pod亲和性对调度的影响 不使用调度器，手动调度一个pod 了解Daemonset的角色 了解如何配置Kubernetes scheduler 在Kubernetes中有一个kube-scheduler组件，该组件运行在master节点上，它主要负责pod的调度。Kube-scheduler监听kube-apiserver中是否有还未调度到node上的pod（即Spec.NodeName为空的Pod），再通过特定的算法为pod指定分派node运行。如果分配失败，则将该pod放置调度队列尾部以重新调度。调度主要分为几个部分：首先是预选过程，过滤不满足Pod要求的节点。然后是优选过程，对通过要求的节点进行优先级排序，最后选择优先级最高的节点分配，其中涉及到的两个关键点是过滤和优先级评定的算法

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Choerodon平台中的开发和部署都是围绕应用来进行的，那Choerodon平台中的应用有什么样的特性？又是怎样来进行管理的呢？本文旨在深入地介绍Choerodon平台中应用的功能特性及其生命周期的管理。 微服务架构中应用的特征 在谈起Choerodon平台中的应用时，就不得不提微服务。正是因为微服务的出现，之前的单体应用架构带来的问题才得以解决，具体问题如下： （1）耦合程度随时间推移而逐渐提高。 （2）扩展性差，冗余能力差 （3）模块划分不清晰，无法细化对系统资源的需求 （4）维护成本随着系统的日益臃肿而不断增加 而下图也更为直观地指出了单体应用架构与微服务架构的区别。 由此可见，微服务架构中的应用会被分解为更小、完全独立的组件，这使得它们拥有更高的敏捷性、可伸缩性和可用性。换句话说，微服务架构的基本思想就是“围绕业务领域组件来创建应用，让应用可以独立地开发、管理和加速。 Choerodon平台中应用生命周期的管理 由于Choerodon平台采用的是微服务架构，因此系统内每个功能模块均被解耦为多个应用，其中每个应用都支持独立地开发和独立地部署。而Choerodon平台中一个应用的生命周期一般从创建或导入应用开始；接着在开发流水线中按照需求对应用进行开发，待提交代码跑完CI之后，会生成一个应用版本