免费获取策划方案多一份参考,总有益处

重庆网站设计

Website design

案例778

重庆网站设计

设计系统的版本管理

来源:派臣科技|时间:2020-09-09|浏览:

你的设计系统团队是如何通知订阅者新的特性已经发布,bug正在被修复,或者安全漏洞正在被修补?Patrick讨论了版本控制策略和自动化流程的优势。

想象一下,如果你愿意,我们是一个团队的一部分,一起工作来生产一些软件。我们的团队知道,在六个月内,我们的最小可行产品(MVP)需要准备好发布。我们也知道,在最初的版本发布之后,我们的团队将继续对我们的产品进行迭代:我们将修复bug,我们将添加新特性,我们将修补安全漏洞,甚至有一天,我们可能会弃用或删除部分产品。

实际上,我们的产品可以是任何类型的软件,但在本文的其余部分中,我将描述的产品是一个设计系统,由许多单独的组件组成。作为设计系统的生产者,我们将自己称为为订阅者维护系统的发布者。

项目和产品

在我职业生涯的大部分时间里,我都在机构从事项目工作,而这些项目大部分都围绕着网站和网络应用。这些项目通常都有一个结束日期,也就是启动日期。即使当我的同事和我与其他团队合作提供长期支持和维护时,这种类型的工作在计划、路线图和用户关注方面也不同于产品工作。

在设计系统的上下文中尤其如此,其中设计系统团队的角色是发布者,而受众的角色是订阅者。Nathan Curtis谈到了从项目到产品思维模式的转变,他指出,一个系统是“一个活的、不断发展的、将服务于其他产品的产品的起源故事”。

对我来说,这种心态转变的有趣之处在于,很多人——如果不是所有人的话——已经习惯了扮演我提到的其中一个角色。不管我们是否意识到,我们都是订阅用户。

想想看:你最近有没有更新安卓或iOS应用程序?你是否在公寓或家里为物联网设备安装了新版本的固件或软件?你有升级到最新版本的Windows或MacOS吗?我觉得很有可能是你干的祝贺您,您是软件的一部分(或多个部分)的订阅者。

现在,想一下这个的另一边。如果您负责创建和维护我上面提到的某个软件,您将如何向您的订阅者表明您的团队已经在软件中构建了新特性、修复了漏洞或修补了安全漏洞?您需要向您的订阅者提供哪些关于您的更改的文档?要使发布者到订阅者的过程发生,您需要什么样的工作流?

我在这里暗示的是一个发布策略,它由三个概念组成:为我们的整个设计系统或每个单独的组件维护一个版本号方案。2. 创建一个变更记录——一个变更日志——这样我们的订阅者就知道这个版本和上一个版本有什么不同。3.将系统或其组件的新更新版本发布到订阅者可以使用它的地方。

让我们再深入研究一下这些概念。

版本

我们的团队在过去的六个月里努力工作,我们的MVP已经准备好要发布给全世界了!恭喜你!我们终于发布了1.0版!但是这个版本号代表什么?它来自哪里?当我们不可避免地要对我们的产品进行一些更改时,下一个版本号是什么?

语义版本控制(Semantic Versioning, Semver)是一种流行的规范,我们的行业使用它来描述公共接口版本之间的变化。每个版本都直接绑定到一个版本号上,该版本号由三个用句点分隔的数字组成。这三个数字分别表示主、小和补丁(例如:3.10.2),每个数字都有一系列有序的版本。Semver网站将major、minor、patch的语义差异总结如下:

给出一个版本号MAJOR.MINOR。补丁,增加:1。当你做不兼容的API更改时,主要版本2。当您以向后兼容的方式添加功能时,将使用次要版本;修正向后兼容的错误时的补丁版本。”

我并不打算在本文中详尽地介绍Semver及其复杂性,但是了解major、minor和patch非常重要——尤其是在Node上下文中。因为Semver内建在npm管理其包的方式中。检查包。json用于我们的弹跳球项目,这是一个很好的练习,可以轻松理解项目如何管理它的包。当您查看这里列出的依赖项和devDependencies时,打开这个备忘单,看看我们的包是如何运行的。json指的是版本和范围。

版本控制…什么?

既然我们已经讨论了版本和版本号背后的一些含义,那么让我们来讨论一下我们到底在控制什么版本。在本文的开始部分,我们设想我们的团队正在努力为我们的设计系统构建组件。当我们开始我们的项目时,我们决定使用Git将我们所有的设计系统代码包含在一个存储库中。

在开始的时候,我们的团队需要决定它作为发布者的角色:我们的订阅者应该如何使用我们的组件?设计系统应该是它自己的单一包,订户带进他们的项目,批发?或者设计系统应该是许多可单独订阅的包的容器,让我们的消费者选择他们想要的包以及这些包何时更新?

这两种策略都有利有弊,在我看来,大多数的利弊都是围绕着计划,以及出版商和订阅者应该把他们的时间和精力花在哪里和如何上。

例如,如果您的设计系统作为一个单独的包来管理和发布,您的团队可能会发现开发一个发布周期是有利的——可能是每月或每季度。随后,团队可能会发现它可以预测每个版本的特性、修复和其他工作的数量。这种可预测性不仅可以帮助发布团队,还可以帮助订阅团队制定计划和路线图。

相反,也许你的订阅者不想更新到整个设计系统的最新版本——也许他们不能。可能有一个或一组包他们无法更新,他们现在面临着落后的风险,直到他们能够优先更新。也许,如果设计系统单独发布它的软件包,订阅者将能够根据他们自己的条款更新到这些更新的软件包。

无论您的团队选择哪种管理策略——单个包还是多个、单独的包——重要的是要关注您的订阅者。考虑一下,如果您是订阅者,您希望如何让更新和发布传递给您。想想你的订阅者需要什么才能保持最新,想让他们更新或迁移到你的最新版本需要什么。尝试考虑每个更新的下游影响,无论它们是单个包还是多个包。最终,团队的利益相关者就是它的订阅者。

但是,不要让这压倒了你的团队。安慰的事实,你的团队是由聪明的人谁习惯于成为订户。鼓励他们想想上一次在其他项目中更新Rails或npm依赖项是什么时候,以及那种体验是什么样的。

版本控制…如何?

我刚刚讨论了哪些团队将进行版本控制,但是我还想提到团队如何使版本控制过程更容易、更准确。

首先,您可能知道(也可能不知道)包含许多包的存储库通常被称为单一存储库。使用monorepo方法的一些流行项目的例子包括Babel、React、Meteor和Jest。假设我们的设计系统项目是由许多包(我们的组件)组成的,那么我们的设计系统也可以被称为单体系统是有意义的。

包括我上面列出的那些流行的,单一pos倾向于分享的一个特点是,他们利用自动化来管理他们的版本号。不管你的设计管理系统作为一个单独的包或尽可能多的个人包,我想我们都同意,我们的团队应该花费时间构建惊人的组件和解决问题subscribers-not陷入困境在如何包需要撞他们的下一个版本,这些版本是什么,等等。坦白地说,不自动化这个过程听起来像是导致混乱和最终的灾难。

幸运的是,有一个名为Lerna的工具可以帮助管理使用Git和npm的单机操作流程。Lerna最初是作为管理巴别塔单矿石的工具开始的,在它被提取出来成为它自己的独立工具之前。

Lerna将处理你的版本,但它真的照当你深究它的一些其他功能,如结合它与传统致力于自动生成更新日志文件和配置注册表自动发布你的包,这是我们将会讨论接下来的两个概念。

更新日志

我们以前讨论过编写发布说明,但是维护设计系统中所有组件的发布说明或更改日志对于您的订阅者来说是非常重要的,这可能会让人望而生畏。幸运的是,有一些工具可以为您自动执行这个过程。

我在上面提到过,您可以使用Lerna自动生成更改日志文件,但是如果您不使用Lerna,另一个需要研究的工具是semantic-release。这个工具将自动化整个发布工作流,包括确定下一个版本号,生成发布说明,以及发布一个或多个包。

Lerna和语义发布都使用存储库的提交消息,不仅可以理解要执行的版本增量的类型,还可以编译每个发布生成的变更日志。这对于您的团队来说是非常强大的,因为只要他们坚持传统提交规范,变更日志生成的自动化过程——以及版本号的递增——就会自行处理。剩下的惟一部分就是将最新更新和文档化的包分发给您的订阅者。

发布到注册表

我们已经增加了版本号,我们已经创建了变更日志来描述我们的变更,现在是时候将我们的包发送到订阅者可以获得它们的地方了——通常称为包注册表。

在Node的上下文中。npm是最流行的注册——特别是对于公开可用的节点包。GitHub现在拥有npm,它有自己的包注册表,允许公有和私有发布,JFrog Artifactory也允许私有发布。

包发布是我们工作流程的另一部分,如果手工完成,可能会令人生畏。如果您认为这是我提倡自动化流程的另一种情况,那么您是对的!幸运的是,我上面提到的两个工具,Lerna和语义发布,是为了自动发布包而构建的。

为了发布包,这两种工具都会执行类似的过程,以确定注册中心中是否存在具有相应版本号的包。只有在注册表中不存在与其对应的版本号时,包才会被发布。这可以防止您的包覆盖自己,并防止新更改污染已经发布的包。您的订阅者将知道任何递增的版本号都表明他们试图更新的软件包有了一些新的变化。

通过自动化释放

作为开发人员,我们知道自动化我们的流程和工作流的好处。将设计系统发布后的过程自动化(管理版本号、编译变更日志和处理包发布)可以让您的团队专注于真正重要的事情:通过构建和维护优秀的软件,成为订阅者的优秀合作伙伴。

留言

返回顶部

君
重庆网站建设重庆网站设计设计系统的版本管理