Skip to main content

2 篇博文 含有标签「版本控制

View All Tags

· 32 分钟阅读

在此之前您可能听说过“GitOps”,但并不知道它到底是什么,除了GitOps,您可能还听说过DevOps,或者AIOps、GOps等,是的,现在是“Ops”盛行的时代。

GitOps是一种实现持续交付的模型,它的核心思想是将应用系统的声明性基础架构和应用程序存放在Git的版本控制库中。Choerodon猪齿鱼在构建持续交付流水线时参考了GitOps,并进行了实践,俗话说“兵马未动,理论先行”,在本文中,将重点阐述GitOps工作流程的原理和模式,以及将它们应用在生产和大规模运行Kubernetes中的一些实践经验。 在下一篇文章中,将介绍Choerodon猪齿鱼是如何实践和落地GitOps,从而构建了一个可重复且可靠的交付过程。

GitOps,90%的最佳实践,10%有意思的新东西需要我们去构建。 —— 《​GitOps - Operations by Pull Request》来自:https://www.weave.works

这篇文章是根据Weave Cloud的几篇关于GitOps的文章翻译整理而来:

GitOps

GitOps: Operations by Pull Request

The GitOps Pipeline - Part 2

GitOps - Part 3: Observability

GitOps - Part 4: Application Delivery Compliance and Secure CICD

主要内容:

  • 什么是GitOps?
    • GitOps的主要优点
  • GitOps的应用场景——适合云原生的持续交付
  • GitOps的基本原则
  • 最佳实践
    • 拉式流水线——Pull Request操作
    • GitOps工作流
    • 可视化
    • 应用交付的合规性和安全的CI/CD
  • GitOps带来的价值

什么是GitOps?

GitOps是一种持续交付的方式。它的核心思想是将应用系统的声明性基础架构和应用程序存放在Git版本库中。

将Git作为交付流水线的核心,每个开发人员都可以提交拉取请求(Pull Request)并使用Gi​​t来加速和简化Kubernetes的应用程序部署和运维任务。通过使用像Git这样的简单熟悉工具,开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上(例如,应用系统安装、配置、迁移等)。

GitOps: versioned CI/CD on top of declarative infrastructure. Stop scripting and start shipping. https://t.co/SgUlHgNrnY — Kelsey Hightower (@kelseyhightower) January 17, 2018

作为一个有经验项目管理者,或者产品负责人,你一定会思考一个问题:我们项目组在开发过程中应如何管理分支?不错,分支管理将和项目组开发人员日夜伴随,如果采用了一个不合适的分支管理模型,那么可以想象兄弟们得多么的痛苦。

Okay,那么就从分支管理模型开始......

GitOps的主要优点

通过GitOps,当使用Git提交基础架构代码更改时,自动化的交付流水线会将这些更改应用到应用程序的实际基础架构上。但是GitOps的想法远不止于此——它还会使用工具将整个应用程序的实际生产状态与基础架构源代码进行比较,然后它会告诉集群哪些基础架构源代码与实际环境不匹配。

通过应用GitOps最佳实践,应用系统的基础架构和应用程序代码都有“真实来源”——其实是将基础架构和应用程序代码都存放在gitlab、或者github等版本控制系统上。这使开发团队可以提高开发和部署速度并提高应用系统可靠性。

将GitOps理论方法应用在持续交付流水线上,有诸多优势和特点:

  • 安全的云原生CI/CD管道模型 
  • 更快的平均部署时间和平均恢复时间 
  • 稳定且可重现的回滚(例如,根据Git恢复/回滚/ fork)
  • 与监控和可视化工具相结合,对已经部署的应用进行全方位的监控

GitOps应用场景——满足云原生环境下的持续交付

作为CI / CD流水线的方案,GitOps被描述为软件开发过程的“圣杯”。 由于没有单一工具可以完成流水线中所需的所有工作,因此可以自由地为流水线的不同部分选择最佳工具。可以从开源生态系统中选择一组工具,也可以从封闭源中选择一组工具,或者根据使用情况,甚至可以将它们组合在一起,其实,创建流水线最困难的部分是将所有部件粘合在一起。

不管如何选择构造自己的交付流水线,将基于Git(或者其他版本控制工具)的GitOps最佳实践应用在交付流水线中都是一个不二选择,这将使构建持续交付流水线,以及后续的推广变得更加容易,这不仅从技术角度而且从文化角度来看都是如此。

当然,GitOps也不是万能的,它也有相应的应用场景。

不可变基础设施

应用都需要运行在多台机器上,它们被组织成不同的环境,例如开发环境、测试环境和生产环境等等。需要将相同的应用部署到不同的机器上。通常需要系统管理员确保所有的机器都处于相同的状态。接着所有的修改、补丁、升级需要在所有的机器中进行。随着时间的推移,很难再确保所有的机器处于相同的状态,同时越来越容易出错。这就是传统的可变架构中经常出现的问题。这时我们有了不可变架构,它将整个机器环境打包成一个单一的不可变单元,而不是传统方式仅仅打包应用。这个单元包含了之前所说的整个环境栈和应用所有的修改、补丁和升级,这就解决了前面的问题。 —— 摘自InfoQ的《关于不可变架构以及为什么需要不可变架构》作者 百占辉

“不可变基础设施”这一概念不是刚刚冒出来的,它也不是必须需要容器技术。然而,通过容器,它变得更易于理解,更加实用,并引起了业内广泛注意。“不可变基础设施”让我们以全新的方式理解和面对应用系统,尤其是使以微服务为代表的分布式系统在部署、运营等方面变得不那么复杂,而有很好的可控性。

那么,如何比较方便地在实际的生产过程中应用“不可变基础设施”,这给业界也提出了另外一个问题。GitOps是在具体Kubernetes的应用实践中出现的,GitOps需要依托于“不可变基础架构”才能发挥其作用。在一定程度上说,“不可变基础架构”为GitOps的出现创造了必要的条件,反过来GitOps应用Kubernetes的容器编排能力,能够迅速的使用镜像搭建出应用系统所需的组件。

声明性容器编排

Kubermetes作为一个云原生的工具,可以把它的“声明性”看作是“代码”,声明意味着配置由一组事实而不是一组指令组成,例如,“有十个redis服务器”,而不是“启动十个redis服务器,告诉我它是否有效”。

借助Kubermetes的声明性特点,应用系统的整个配置文件集可以在Git库中进行版本控制。通过使用Git库,应用程序更容易部署到Kubernetes中,以及进行版本回滚。更重要的是,当灾难发生时,群集的基础架构可以从Git库中可靠且快速地恢复。

Kubernetes等云原生工具的声明性体现在可以对实例、容器、网络、存储、CPU等配置通过一组代码方便的表达出来,Kubernetes等云原生工具可以利用这些配置代码运行出来一套基于容器的应用系统,例如YMAL,

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: registry.choerodon.com.cn/operation-choerodon-dev/nginx-demo:1.13.5-alpine
ports:
- containerPort: 80

GitOps充分利用了不可变基础设施和声明性容器编排,通过GitOps可以轻松地管理多个部署。为了最大限度地降低部署后的变更风险,无论是有意还是偶然的“配置偏差”,GitOps构建了一个可重复且可靠的部署过程,在整个应用系统宕机或者损坏情况下,为快速且完全恢复提供了所需条件。  

GitOps的基本原则

以下是几条在云原生环境中,GitOps的原则:

  • 任何能够被描述的内容都必须存储在Git库中

    通过使用Git作为存储声明性基础架构和应用程序代码的存储仓库,可以方便地监控集群,以及检查比较实际环境的状态与代码库上的状态是否一致。所以,我们的目标是描述系统相关的所有内容:策略,代码,配置,甚至监控事件和版本控制等,并且将这些内容全部存储在版本库中,在通过版本库中的内容构建系统的基础架构或者应用程序的时候,如果没有成功,则可以迅速的回滚,并且重新来过。

  • 不应直接使用Kubectl

    作为一般规则,不提倡在命令行中直接使用kubectl命令操作执行部署基础架构或应用程序到集群中。还有一些开发者使用CI工具驱动应用程序的部署,但如果这样做,可能会给生产环境带来潜在不可预测的风险。  

  • 调用Kubernetes 的API的接口或者控制器应该遵循 Operator 模式

    调用Kubernetes 的API的接口或者控制器应该遵循 Operator 模式(什么是Operator 模式?),集群的状态和Git库中的配置文件等要保持一致,并且查看分析它们之间的状态差异。

最佳实践

以Git作为事实的唯一真实来源

Git是每个开发人员工具包的一部分。学习起来感觉自然而且不那么令人生畏,而且工具本身也非常简单。 通过使用Git作为应用系统的事实来源,几乎可以操作所有东西。例如,版本控制,历史记录,评审和回滚都是通过Git进行的,而无需使用像kubectl这样的工具。

所以,Git是GitOps形成的最基础的内容,就像第一条原则“任何能够被描述的内容都必须存储在Git库中 ”描述的那样:通过使用Git作为存储声明性基础架构和应用程序代码的存储仓库,可以方便地监控集群,以及检查比较实际环境的状态与代码库上的状态是否一致。所以,我们的目标是描述系统相关的所有内容:策略,代码,配置,甚至监控事件和版本控制等,并且将这些内容全部存储在版本库中,在通过版本库中的内容构建系统的基础架构或者应用程序的时候,如果没有成功,则可以迅速的回滚,并且重新来过。

拉式流水线——Pull Request操作

推送流水线  

目前大多数CI / CD工具都使用基于推送的模型。基于推送的流水线意味着代码从CI系统开始,通过一系列构建测试等最终生成镜像,最后手动使用“kubectl”将任何更改推送到Kubernetes集群。

很多开发人员不愿意在CI中启动CD部署流程,或者使用命令行工具操作启动CD部署流程的原因可能是这样做会将集群的用户和密码等公布出去。虽然可以有措施保护CI / CD 脚本和命令行,但是这些操作毕竟还是在集群外部非可信区工作的。所以,类似做法是不可取的,会给系统安全带来潜在的风险。

具有集群外读/写(R/W)权限的典型推送流水线:

  • CI运行测试,输出传递到容器映像存储库。
  • CD系统自动部署容器(或根据请求,即手动)。

拉式流水线

在GitOps中,镜像被拉出并且凭证保留在集群中:

Git库是拉式流水线模式的核心,它存储应用程序和配置文件集。开发人员将更新的代码推送到Git代码库; CI工具获取更改并最终构建Docker镜像。GitOps检测到有镜像,从存储库中提取新镜像,然后在Git配置仓库中更新其YAML。然后,GitOps会检测到群集已过期,并从配置库中提取已更改的清单,并将新镜像部署到群集。

GitOps的流水线

在上节中介绍了GitOps采用拉式模式构建交付流水线,本节将详细地介绍在构建GitOps流水时需要注意哪些事情,有哪些最佳实践。

GitOps流水线

这是一个新图,显示部署上游的所有内容都围绕Git库工作的。在“拉式流水线”中讲过,开发人员将更新的代码推送到Git代码库,CI工具获取更改并最终构建Docker镜像。GitOps的Config Update检测到有镜像,从存储库中提取新镜像,然后在Git配置仓库中更新其YAML。然后,GitOps的Deploy Operator会检测到群集已过期,并从配置库中提取已更改的清单,并将新镜像部署到群集。

使用群集内部的Deploy Operator,群集凭据不会在生产环境之外公开。一旦将Deploy Operator安装到集群与Git仓库建立连接,线上环境中的任何更改都将通过具有完全回滚的Git pull请求以及Git提供的方便审计日志完成。

自动git→集群同步 

由于没有单一工具可以完成流水线中所需的所有工作,可以从开源生态系统中选择一组工具,也可以从封闭源中选择一组工具,或者根据使用情况,甚至可以将它们组合在一起,其实,创建流水线最困难的部分是将所有部件粘合在一起。要实现GitOps,必须要开发出新的组件,用于粘合这些工具,实现拉式交付流水线

部署和发布自动化是应用落实GitOps,并使交付流水线工作的基础。GitOps不仅要保证,当开发人员通过Git更新配置文件集的时候,GitOps流水线要自动根据最新的配置文件状态更新线上环境,而且GitOps还要能够实时比对Git库中配置文件集最新的状态与线上环境最新的状态保持一致。

在上节中提到了两个名词:Config UpdateDeploy Operator,根据GitOps的实践,Config Update 和 Deploy Operator是需要进行设计开发的,它们是实现GitOps流水线必须的关键组件。GitOps赋予了它们神奇的魔法,它们既是自动化容器升级和发布到线上环境的工具,可能也要负责服务、部署、网络策略甚至路由规则等任务。因此,Config Update 和 Deploy Operator是映射代码,服务和运行集群之间所有关系的“粘合剂”

当然,您可以根据具体的设计,赋予各种其他的功能,但是自动同步是一定需要的,确保如果对存储库进行任何更改,这些更改将自动部署到线上环境中

仅部署容器和配置

GitOps建议不直接将应用程序部署到线上环境中,而是将应用程序和相关配置打包成镜像,并存储到镜像库中,最后,通过镜像的方式生成容器,并部署到线上环境中。

容器为什么如此重要?在GitOps模型中,我们使用不可变基础架构模式。一旦代码在Git中提交,GitOps就不希望任何其他内容发生变化,这样可以最大限度地降低系统潜在不确定性、不一致性风险。例如,需要将相同的应用部署到不同的机器上。通常需要系统管理员确保所有的机器都处于相同的状态。接着所有的修改、补丁、升级需要在所有的机器中进行。随着时间的推移,很难再确保所有的机器处于相同的状态,同时越来越容易出错。然而,容器是比较完美地解决了这个问题,当然,使用虚拟机是可以的,显然使用容器更加方便。

GitOps的可观察性

“可观察性就像生产中的驱动测试一样。如果你不知道如何确定它是否正常工作,请勿接受 pull request。@mipsytipsy “ - Adriano Bastos

在GitOps中,使用Git库来存储应用系统的配置文集和应用程序,它确保开发人员将所有对于应用系统的配置和程序的新增、修改等都通过Git库进行版本控制,使Git成为配置和程序的唯一真实来源。而GitOps的可观察性则是确保线上环境的真实状态与Git库中的保持一致性。本章节将给大家介绍GitOps的可观察性。

可观察性是另一个真理来源

在GitOps中,我们使用Git作为系统所需状态的真实来源。例如,如果应用系统宕机,GitOps可以回滚到之前正确状态。而可观察性是系统实际运行状态的真实来源,系统开发人员或者运维人员可以监控系统的状态。这是一张显示流程的图片。

通过观察需寻找问题的答案

如果大家使用Kubernetes作为云原生环境和容器编排工具,相信大家会有这样的感触,虽然Kubernetes是一个非常棒的编排容器平台,但是随之而来的缺乏友好的可视化管理界面给开发人员或者运维人员带来诸多不便。例如:

  • 我的部署成功了吗?我的系统现在处于工作的状态,我现在可以回家吗?
  • 我的系统与以前有什么不同?我可以使用Git或我们的系统历史记录来检查吗?
  • 我的改变是否改善了整体用户体验?(与系统正确性相对)
  • 我在信息中心找不到我的新服务(例如RED指标)
  • 这个故障是否与我上次的服务更新事件有关,还是和其他操作有关系?

大家可能会想到通过监控服务器的CPU、内存、网络等,以及应用的日志,甚至微服务的调用链等来解决问题。是的,这个没有错,能够得到一些反馈信息,但是使用过类似监控的开发人员或者运维人员也会感觉,这些监控仪表盘给我们大量冗繁的信息,需要认真地甄别,而且有很多信息在这些仪表盘中是获得不到的。这意味着需要创建新的仪表盘,用于监控新的指标和内容。

GitOps的可观察性

可观察性可被视为Kubernetes 持续交付周期的主要驱动因素之一,因为它描述了在任何给定时间系统的实际运行状态。观察运行系统以便理解和控制它。新功能和修复程序被推送到git并触发部署管道,当准备好发布时,可以实时查看正在运行的集群。此时,开发人员可以根据此反馈返回到管道的开头,或者将映像部署并释放到生产集群。

在这里GitOps引入一个新的工具:Diffs,用来监控对比系统状态。即:

  • 验证当前线上系统的状态是否和Git库中描述的状态一致,例如,我上一次发布是否符合期望?
  • 提醒开发人员不一致状态,以及相应的明细信息。

在文章前面讲过,在Git库中存储的实际上是“声明性基础设施”,例如Kubernetes的YAML文件,用以构建应用系统所需的各种组件、域名、网络等配置信息。Diffs需要读取Git库中配置信息,同时,通过API等读取集群的相应信息,并进行比对。

例如,Kubernetes集群:所需的Kubernetes状态可能是“有4个redis服务器”。Diffs定期检查群集,并在数量从4变化时发出警报。一般而言,Diffs将YAML文件转换为运行状态查询。

GitOps是面向发布的操作模型,请参见下图。交付速度取决于团队在此周期中绕过各个阶段的速度。

应用交付合规性和安全性

由于以安全的方式跟踪和记录更改,因此合规性和审计变得微不足道。使用Diffs等比较工具还可以将Git库中定义的集群状态与实际运行的集群进行比较,从而确保更改与实际情况相符。

在Git中记录所有的操作日志

通过上面文章的叙述,开发人员或者运维人员通过Git操作系统配置和应用程序的新建和更新等。通过Git客户端git commit /git merge的所有操作都会Git库记录下来,审计员可以查看Git,看看谁做了任何更改,何时以及为何以及如何影响正在运行的系统部署。当然,可以根据自身的需求定制不同的交付合规性。相较于直接进入服务器操作或者通过Kubctl操作集群,Git记录了每一个操作步骤,这些可以为合规性和审计提供完整的操作日志。

角色和权限控制

几乎所有的Git库都提供角色和权限控制,与开发和运维无关的人员没有权限操作Git库。而不是直接把服务器或者集群的操作权限散发出去,这样特别容易引起安全泄露。

GitOps带来的好处

更加快速地开发

借助GitOps的最佳实践,开发人员可以使用熟悉的Git工具,便捷地将应用程序和其对应的配置文件集持续部署到Kubernetes等云原生环境,提高业务的敏捷度,快速地相应用户的需求,有助于增加企业市场的竞争力。

更好地进行运维

借助GitOps,可以实现一个完整的端到端的交付流水线。不仅可以实现拉式的持续集成流水线和持续部署流水线,而且系统的运维操作可以通过Git来完成。 更强大的安全保证 几乎所有的Git库都提供角色和权限控制,与开发和运维无关的人员没有权限操作Git库。而不是直接把服务器或者集群的操作权限散发出去,这样特别容易引起安全泄露。

更容易合规的审计

由于以安全的方式跟踪和记录更改,因此合规性和审计变得微不足道。使用Diffs等比较工具还可以将集群状态的可信定义与实际运行的集群进行比较,从而确保跟踪和可审计的更改与实际情况相符。

关于猪齿鱼

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

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

· 16 分钟阅读

现在越来越多的项目使用Git作为版本控制的工具,通过Git进行分支和Tag管理,大多数情况这个过程都由手工完成,缺乏相应的规范,对于分支和版本号的控制也很随意,出现这样的情况往往是大家对软件交付过程中的软件版本控制不够重视,“只要确保软件是最新的版本即可”,甚至是项目管理的漏洞或者缺陷。其实软件的版本控制以及分支管理贯穿于整个软件产品的生命周期,日常的项目管理对于开发团队能否有节奏且顺利的交付软件也很重要。

的确!频繁的冲突搞的开发人员头晕脑胀,例如,一次项目在代码合并时出现了冲突,导致整个项目组挨个排查,花费了大半天的时间,影响开发效率还浪费资源;开发人员随意创建分支,各种不规范的合并使得Git Graph线条杂乱无章,完全看不出来主干发展的脉络;提交信息混乱,不知道这次提交是因为什么,实现了什么功能 ,解决了什么问题。

本文并不是一篇技术文章,其中也没有让别人耳目一新的观点或者论述。本文是为我们这些希望进行简单、有效地协作的人准备的。任何参与到软件开发的人,无论承担何种角色,都可能对其感兴趣——毕竟每个人都会用到分支和合并。本文将结合Choerodon猪齿鱼为大家阐述如何进行方便有效的分支管理和版本控制,以及如何选择适合自身的版本控制模型。

如何来解决这些问题呢?

有经验的老司机可能会说,“建立规范”。

是的,只有建立规范,才能抑制不好的事情继续在项目组蔓延。至于建立什么样的规范?我们不妨先制定一个目标。

目标

  • 简单——所有的团队成员每天都会使用这些模式,所以相关规则和程序必须要简单明了。
  • 灵活——可选择不同的分支管理模型,例如GitFlow、GitLabFlow或者GitHubFlow,甚至自定义。
  • 可视化——界面化比命令行更安全可控,将分支管理模型的规则和约定固化到系统中。
  • 需求与代码关连——分支需要和具体的任务需求关连。

作为一个有经验项目管理者,或者产品负责人,你一定会思考一个问题:我们项目组在开发过程中应如何管理分支?不错,分支管理将和项目组开发人员日夜伴随,如果采用了一个不合适的分支管理模型,那么可以想象兄弟们得多么的痛苦。

Okay,那么就从分支管理模型开始......

分支管理规范

GitFlow、GitHubFlow等都是已经被证明很有效的分支管理模型,但是这些更多的是书面的规则、约定,基本上是靠着程序员的自觉性和Git命令一起维持着这个约定,其实无数的经验告诉我们“这很脆弱”。所以,如何使用系统界面化操作将这些规则和约定表示出来,就变得很有意思。

分支管理模型

不要着急,先来看看 Choerodon 猪齿鱼提供的分支模型,Choerodon使用 GitLab 进行分支管理,默认分支为 master。目前支持七种常见的分支类型:

  1. master:主分支,用于版本持续发布;
  2. develop:开发分支,即日常迭代使用的开发分支,用于日常开发持续集成;
  3. feature:特性分支,用于日常开发时切出分支进行单功能开发;
  4. bugfix:故障修补分支,通常用于修复故障;
  5. release:发布分支,适用于产品发布、产品迭代;
  6. hotfix:热修分支,用于产品发布后修复缺陷;
  7. custom:自定义分支,用户可以自定义需要的分支类型。

注:

  1. develop是GitFlow分支模型的重要组成部分。
  2. bugfix旨在与敏捷的问题类型(故障)呼应,用于标识此分支的任务是修复某个故障。

这7个分支就是我们手中的7个魔方,通过这7个魔方的组合可以变化出无尽的分支管理模型,比如GitHubFlow。

GitHubFlow分支模型只存在一个master主分支,日常开发都合并至master,永远保持其为最新的代码。

  • 在领到日常开发任务时,基于master创建feature特性开发分支,提交代码后,合并至master并删除feature。
  • 在领到修复故障的任务时,基于master创建bugfix故障修补分支,提交代码后,合并至master并删除bugfix。
  • 需要发布时,同样需要基于master创建release,生成的应用版本部署在UAT测试环境进行测试,若需要修改则提交至release。
  • 产品上线后发现故障需要紧急进行热修复时,则基于tag创建hotfix,将修复的代码提交至hotfix;部署该分支上的版本通过验收后,基于hotfix打出热修版本的tag,如0.8.1。
  • 由于新版本的迭代也同时进行,所以需要在hotfix上rebase master,变基至master分支最新的提交,再合并至master并删除hotfix,就可以将本次修改的提交应用至master上。

这个分支模型的优势在于简洁易理解,将master作为核心的分支,代码更新持续集成至master上。根据目前收集到的反应来看,得到了更多的好评,认为GitHubFlow分支模型更加轻便快捷。

如果GitHubFlow不合适,可以使用GitLabFlow或者GitFlow,也可以自行定义规则。这里没有“银弹”,只是相对比较灵活的配置。

分支命名规约

有了分支管理模型,还需要命名规约,不同类型的分支命名方式应该不同,值得庆幸的是,猪齿鱼已经帮你完成了这个步骤。feature、bugfix分支的分支名使用的是关联问题的issue号(在猪齿鱼中打通了需求和代码分支的关连关系),对于release及hotfix,分支名可命名为需要发布的版本号,如0.8.0、0.8.1等。在这里使用到了类似0.8.0这样的版本编号规则,如果你对此不了解,没有关系,在下面将详细的介绍。

提交命名规约

除了分支的名称需要规范,提交的命名也同样如此。不幸,猪齿鱼并没有把这个规则固化到系统中,需要团队共同遵守。

格式为:[操作类型]操作对象名称,如[ADD]readme,代表增加了readme描述文件。

常见的操作类型有:

  • [IMP] 提升改善正在开发或者已经实现的功能
  • [FIX] 修正BUG
  • [REF] 重构一个功能,对功能重写
  • [ADD] 添加实现新功能
  • [REM] 删除不需要的文件

合并请求

合并请求是开发过程中必不可少的一个环节,其中有如下一些重要的事情要做:

  1. 代码Review
  2. 启动CI
    • 单元测试
    • 代码质量检查

版本号规则

在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷,系统规模越大,加入的套件越多,你就越有可能在未来的某一天发现自己已深陷绝望之中。
—— Tom Preston-Werner 的《语义化版本2.0.0》

在这里我们不去解读到底什么是“依赖地狱”,大家可以到语义化版本2.0.0中了解。那么,我们的重点是什么呢?在这之前,先了解一下“语义化的版本控制”

版本格式:主版本号.次版本号.修订号,版本号递增规则如下:

1.主版本号:当你做了不兼容的 API 修改,
2.次版本号:当你做了向下兼容的功能性新增,
3.修订号:当你做了向下兼容的问题修正。

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。

这就是“语义化的版本控制”最核心的规则,当然这不是全部,Tom Preston-Werner还详细的阐述了主版本号、次版本号和修订号的变化递增规则,不过这些规则很长,很复杂。

没有关系,猪齿鱼帮我们做了这些复杂的事情,将“语义化的版本控制”固化到了系统中,简而言之,

  • 当进行代码打包时,而非发布新版本

将版本号规则定为年.月.日-时分秒-分支名。如:2018.7.20-152837-hotfix-0.8.1,这个时间是当前提交时间。当代码提交到各个分支上时会自动触发CI,生成版本号规则如上所示。

  • 当需要发布新版本时,例如如0.8.00.8.1
    • 主版本号:当做了不兼容的 API 修改或功能强大的升级,可以将主版本号的数值增加1。
    • 次版本号:当做了向下兼容的功能性新增或是功能上的小迭代,可以将次版本号的数值增加1。
    • 修订号:当做了向下兼容的问题修正,但功能上没有很大的变化,可以将修订号的数值增加1。

需求与代码关连

一直以来,需求一般和系统的功能联系在一起,但是与代码关连却不常见,如果能将需求和代码联系在一起,奇妙的化学反应就发生了。

“我们可以追溯到一个用户故事对应了哪些分支,哪几个提交”, “甚至出现了一些BUG,可以找到是哪个分支提交的,当初为了发布XXX新的需求”, “不仅如此,我们通过需求与代码分支关连,能够查看到哪些需求已经部署到了测试环境,那些需求已经部署到了正式环境”, “可以做从业务到代码的整个链条的统计分析...”

...

这一切,猪齿鱼已经帮助项目管理者和程序员实现了。在猪齿鱼的敏捷管理服务中,可以通过用户故事、任务、缺陷等直接一键创建分支,然后,你可以从git checkout -b 开始愉快而又有挑战的一天。不仅如此,也可以在分支管理中,将现有的分支关连到用户故事、任务或者缺陷。

总结

回顾一下我们的目标,简单、灵活、可视化,以及需求与代码关连。版本控制一直都是一件说起来容易,做起来难的事情,但是我们做到了,重要的是猪齿鱼将这些特点和规则固化到了DevOps流程中,让我们忘记复杂易错的操作,把精力放到业务开发上。希望我们的分享能够给大家带来帮助。

关于猪齿鱼

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

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