Skip to main content

3 篇博文 含有标签「DevOps

View All Tags

· 14 分钟阅读

在之前的文章《持续集成与持续交付之间的联系和区别》中,我们提到了持续集成与持续交付的基本概念以及两者之间的联系和区别。而本文将更进一步,旨在为大家详细介绍如何通过Choerodon 猪齿鱼的CD流水线功能来帮助项目团队实现持续交付。

什么是持续交付

在进行功能介绍之前,我们先来回顾下持续交付的概念。持续交付是指在持续集成的基础上,将集成后的代码持续不断地部署到开发、测试或预生产环境进行测试与验证的能力。也就是说,持续交付是对非生产环境的每一次变更进行交付,而最终选择部署到生产环境的将会是一项完整的功能或一组功能,又或者是一项完整的应用或服务。

上图很好的展示了持续交付的整个流程,在通过持续集成之后,便可以持续地将代码部署至开发或测试环境。最后,待整体功能与需求测试验收完成,就可以将其手动部署至生产环境之中。当然,还需要注意的是:

持续交付并不意味着每一次变化都要尽快部署到生产环境。而是意味着每一次变化都是随时可以部署的。 —— Carl Caum(Caum,2013)

为什么要进行持续交付

众所周知,持续交付是DevOps实践中重要的一环,但持续交付能为团队带来哪些好处呢?

  • 快速发布。能够快速响应业务需求,并更快地实现软件价值;
  • 持续交付倡导的频繁部署以及自动部署,是持续测试的前提,进而提高软件质量;
  • 高质量的软件发布标准。整个交付过程标准化、可重复、可靠;
  • 整个交付过程可视化,方便团队人员了解项目进度;
  • 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少浪费。

如何通过Choerodon实现持续交付?

Choerodon平台通过CD流水线的形式将开发模块与部署模块进行串联,用户只需在流水线中预设对应的部署任务或人工卡点任务,便能将目标应用服务集成后的代码自动部署到开发环境、测试环境、预生产环境以及生产环境(流转至生产环境阶段需要通过设置审批人员)。然后再设置人工卡点任务,即可通过邮件与站内信的方式及时通知到产品负责人或测试人员对新的部署进行验收与测试。

创建持续交付流水线

首先在“部署-应用部署-流水线”菜单页面,点击创建流水线,此时出现下图的流水线创建页面。项目人员可在此按需求定义多个流水线阶段,同时也可在各阶段中定义多个任务。

流水线基础设置

在创建CD流水线时,需自定义该条流水线的名称,并设置该条流水线的触发方式为自动触发或是人工触发;

  • 自动触发:满足所有触发条件时,该流水线才会自动执行。若选择自动触发,则该流水线中阶段一的任务一只能为部署类型的任务来作为触发器。
  • 手动触发:需要手动点击执行,才能触发流水线。若选择手动触发,则需要为该流水线选择触发人员(可多选),只有被选中的人员才有权限执行该流水线。若流水线中含有部署任务,则要求触发人员必须拥有流水线中所有部署任务对应的环境权限。

添加与设置阶段

  • 添加阶段;点击阶段之间的添加按钮,即可成功添加一个阶段;此外还支持修改该阶段的名称,设置阶段之间的流转方式,若选择手动流转,需要为此设置审核人员(可多选,且默认为其中一个人员审核通过则该任务通过,第一个审核人员点击中止则该任务中止)。
  • 任务设置;每个阶段下,需要选择设置对应阶段中任务的执行方式。分别是:任务串行与任务并行,其中任务串行是指阶段中的所有任务从上至下依次执行;并行是指阶段中所有任务同时执行,但阶段中任务并行时,此阶段中便不能添加人工卡点的任务。
  • 只有当一个阶段中的所有任务均执行成功后,才能进入下一阶段。

添加部署任务

为了实现部署流程的可重复性、可靠性以及可伸缩性,持续交付流水线中支持了自动部署的任务类型;但需要在其中配置应用服务、触发版本类型、环境以及实例部署的相关信息,具体步骤如下:

  • 选择任务类型为部署后,需填写任务名称,并在项目下选择一个已存在版本的应用服务;
  • 输入或选择服务版本类型(此处可以选择默认给出的版本类型或手动输入自定义的版本类型。若不填写此栏,则默认自动部署该应用服务的所有版本);
  • 选择环境;只可选择运行中的环境;
  • 选择部署模式(部署模式有新建实例和替换实例两种);
  • 选择部署配置, 此处会根据您选的应用服务与环境自动匹配所有关联的部署配置,您可根据给出的配置信息进行选择。若所选应用服务与环境暂无对应的部署配置,则需要在部署配置页面创建一个对应的部署配置。

若流水线中仅存在这一个部署任务,那么当开发人员提交代码,跑完CI,生成了满足条件的应用服务版本后(生成的版本名称中须包含在任务中定义的版本类型),该条流水线便会被触发。当流水线中存在多个部署任务,第一次触发流水线时,需要满足其中所有流水线的触发条件(生成满足条件的服务版本)。

添加人工卡点任务

人工卡点任务用于为阶段中的部署任务添加控制与审核人员,指定的审核人员审核通过后,流水线才能继续执行。若审核未不通过,整条流水线便会在此任务节点终止。添加人工卡点任务的步骤如下:

  • 选择人工卡点任务类型后,需要填写任务名称,并选择审核人员(可多选);
  • 若选择了多个审核人员,还需选择审核模式,其中包括:会签和或签。(会签是指所选的审核人员全部审核通过后才算通过,其中有一人选择终止,则此任务终止;或签是指所选的审核人员中,一人审核通过后此任务便通过,一人选择终止则此任务终止,以其中第一个审核人员的审核结果为准)。

人工卡点任务创建成功后,当流水线执行到此类型的任务时,会默认通过邮件与站内信的方式告知审核人员。在测试与验收了对应的部署之后,审核人员便可将此任务审核通过,使得流水线继续执行。

查看持续交付流水线记录

CD流水线的每一次执行,都会产生一条执行记录,每条记录里还包含了所有阶段与任务的执行详情。

在“应用部署-部署”菜单页面,项目人员能在列表中查看到流水线部署记录的编号、对应的流水线名称、触发方式、执行者、运行时间以及运行结果;目前,运行结果存在以下几种情况:

运行结果含义
成功流水线中所有任务执行成功
失败流水线中有任务执行失败
执行中流水线中有任务正在运行
待审核流水线正停留在人工审核的节点,包括人工卡点与阶段间的人工审核
已终止人工审核时,点击终止任务,最后流水线为已终止状态
已删除原流水线已被删除,但是执行记录依然保存在此页面

在记录列表中,对不同状态的流水线部署可以执行相应的操作。对于执行失败的流水线,项目所有者可以重新执行流水线中的所有任务;若流水线状态为待审核,则需指定的审核人员审核后才能继续执行;而对于执行中状态的流程,项目所有者可以对其进行强制失败的操作。

点击某条记录的编号,便能查看到该条记录的详情,在此详情页面中,会展示出对应流水线的执行详情。其中包括了流水线的触发方式、触发人员、阶段详情以及任务详情。

总结

总的来说,持续交付是持续不断地将应用服务部署到交付流水线各种环境中的能力。而与持续交付相关的持续集成、持续部署、持续测试、持续反馈以及他们共同作用带来的持续改善,都是DevOps实践落地过程中不可或缺的一部分。

关于猪齿鱼

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

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

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

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

· 8 分钟阅读

通过之前的文章《Choerodon猪齿鱼实践之应用生命周期管理》,我们已经基本了解了Choerodon平台中应用服务的特性和微服务架构的特点。在此基础上,本文将为大家介绍Choerodon平台中导入应用服务的功能。

导入应用服务功能的背景

由于Choerodon平台采用的是微服务架构,因此其中的应用会被分解为更小、完全独立的服务组件,这使得它们拥有更高的敏捷性、可伸缩性和可用性。基于这些特点,我们就可以将各个项目中开发得到的应用服务组件化,并达到复用应用服务的效果,以此来避免重复造轮子的情况。

对于同组织内不同项目之间的应用服务共享,我们在之前的文章中已经进行了详细地介绍(具体步骤请参考:Choerodon猪齿鱼实践之应用服务共享);但是如果想将应用服务共享至其他组织中的某个项目,或者将之前在其他平台中开发的应用服务迁移到Choerodon平台之中,我们要怎样实现呢?这就涉及到下面要介绍的“导入应用服务”的功能。

导入应用服务功能介绍

导入应用服务目前有3个来源,分别是:共享应用(组织内其他项目共享至本项目下的应用服务)、GitHubGitLab。目的是从这些来源中导入已有的应用服务及其对应的代码仓库,并支持在已有应用服务的基础上进行开发,以此来避免重复造轮子的情况。

共享应用

若同组织其他项目下存在符合需求的应用服务,只需通过共享规则的方式将此应用服务共享至本项目即可;而在本项目中导入目标应用服务后,便能在原有代码库的基础上进行二次开发或部署。(注意:选择添加应用服务后,会默认选择该应用服务共享出来的最新版本;若直接导入,此时便会将该服务版本对应的代码库与commit导入到项目之中;此处版本可自主切换)

从GitHub导入

若目标应用服务的代码已经被上传至GitHub之中,此时只需在导入应用服务中选择“从GitHub导入”,再输入GitHub的HTTP地址,便能将应用服务的仓库克隆至本项目下进行二次开发。Choerodon平台目前支持从GitHub公库导入应用服务,且不能导入空库。

此外,Choerodon还在GitHub上预置了多个常用的应用服务模板供各个项目团队选择。只需在“从GitHub导入”的选项中,选择导入来源为“系统预设模板”即可。其中的应用服务模板是由同类型应用服务的代码库整理而成的,引用了相应的应用服务模板后,即可在gitlab中快速地创建初始代码库。其中包括:

  • 微服务-MicroService;
  • web前端-MicroServiceFront;
  • Java库-JavaLib;
  • Java库-SpringBoot;
  • Go库-GoTemplate;
  • 自动化测试-Mocha-ChoerodonMochaTemplate;

在这些模板中,至少都包含了 Dockerfile 文件、CI 文件以及 Chart 目录文件。

其中Dockerfile是由一系列命令和参数构成的脚本,这些命令应用于基础镜像并最终创建一个新的镜像,主要用于控制应用容器化的进程。其次是CI文件,模板中的CI文件主要用于设置在提交代码后,自动集成时要经历的所有阶段。而其中的Chart目录文件则用于将平台中的容器打包,统一置于K8S平台进行管理。

从GitLab导入

若目标应用服务的代码已经被上传至GitLab之中,此时只需在导入应用服务中选择“从GitLab导入”,再输入GitLab的HTTP地址(若为私库,还需输入私有Token)。便能将应用服务的代码仓库克隆至本项目下进行二次开发。Choerodon平台目前支持从GitLab的公库和私库导入应用服务,且同样不能导入空库。

应用服务导入成功之后,系统会默认在本项目对应的 gitlab group 中创建一个 project 作为此应用服务的初始代码库,而后再通过相应的页面功能实现对此应用服务的管理。同时,可以在“代码管理”模块,按照规范的开发流程对导入的应用服务进行分支管理、合并请求管理、版本管理、CI管理、标记管理以及代码质量的监测。

总结

导入应用服务功能使得Choerodon平台中的应用服务更加灵活,不仅仅支持组织内各项目之间应用服务的共享与复用,还可通过GitHub与GitLab导入的方式实现跨组织和跨平台的复用已有的应用服务,充分地发挥微服务架构的敏捷性与可伸缩性。

关于猪齿鱼

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

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

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

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

· 8 分钟阅读

Choerodon平台中的开发和部署都是围绕应用服务来进行的,由此可见应用服务在DevOps实践过程中的重要性。本文旨在为大家介绍Choerodon v0.19及以上版本中的应用服务共享功能。

共享应用服务功能的背景

在详细介绍Choerodon平台中“共享应用服务”功能的使用之前,我们需要知道使用这个功能的原因是什么,以及这个功能可以解决什么问题。在说起Choerodon平台中的应用服务时,我们就不得不提微服务。正是因为微服务的出现,之前的单体应用架构带来的问题才得以解决。而下图也更为直观地指出了单体应用架构与微服务架构的区别。

通过上图,我们不难发现微服务架构中的应用服务会被分解为更小、完全独立的组件,这使得它们拥有更高的敏捷性、可伸缩性和可用性。换言之,微服务架构的基本思想就是:围绕业务领域组件来创建应用服务,让应用服务可以独立地开发、管理和交付。

通过微服务实现了组件化服务的开发和交付后,这些组件化服务按照项目需求组合起来,稍作修改,便是一个可用的产品。因此,尽管项目是暂时性的,但项目团队的交付物却能以组件的形式共享至其他项目,以此来避免重复造轮子的情况。而怎样将已有的应用服务快速地导入或部署到组织下其他项目呢?针对这个问题,共享应用服务的功能应运而生。

怎样使用共享应用服务功能?

当组织下其他项目需要用到本项目下某个应用服务时,项目所有者可以为此应用服务设置共享规则,以此来将对应版本的应用服务共享至其他项目。

以上便是Choerodon平台中共享应用服务功能的大致流程,下面我们就按照这个流程进行展开,带大家了解Choerodon中应用服务的共享功能。

共享应用服务

  • 添加共享规则

首先,选中一个目标应用服务,进入详情界面,选中“共享设置”,点击顶部的“添加共享规则”;在添加共享规则时,项目所有者可以选择将该应用服务的某一类型的所有版本全部共享出去,或者选择一个特定的应用服务版本共享至目标项目。最后选择“共享范围”,那么一条共享规则就这样添加成功了。

  • 目前平台中预置可选的版本类型为以下5种,分别是:master、release、feature、bugfix和hotfix。
  • 此处的版本类型是按照版本名中对应的分支类型来命名的;但可根据需求,在此填写一个自定义的版本类型。
  • 若您想将该类型的所有服务版本共享出去,仅填写版本类型即可,不用再选择特定版本。

共享规则添加成功并生效之后,共享范围之内的项目便能获取到该服务对应版本的代码库与镜像,用于之后的二次开发或直接部署。

  • 管理共享规则

共享规则添加成功之后,可以在之后对其进行灵活地修改或是直接删除;此处支持修改共享规则中的共享版本与共享范围;

共享规则更改后,平台将按照新的共享规则执行,但不会影响其他项目下已部署的实例。

导入共享应用服务

应用服务的接收方,若发现已存在的应用服务并不能完全满足自己的项目需求。便可以选择“导入共享应用服务”,在已有代码库的基础上进行二次开发。

部署共享应用服务

若共享的应用服务已经能够满足项目需求,此时部署人员便可直接在手动部署界面,将该服务对应的版本部署至本项目对应的环境。

总结

共享应用服务的功能支持各个项目团队更方便地围绕业务来进行应用服务的组织,从而使得微服务弹性伸缩的特性可以得到充分地发挥,避免出现重复造轮子的情况。此外,以应用服务为中心进行开发和部署是Choerodon平台实践DevOps的重要步骤,所以应用服务相关的功能与体验也是我们一直都在关注的。

关于猪齿鱼

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

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