你的設計系統(tǒng)團隊是如何通知訂閱者新的特性已經(jīng)發(fā)布，bug正在被修復，或者安全漏洞正在被修補?Patrick討論了版本控制策略和自動化流程的優(yōu)勢。

想象一下，如果你愿意，我們是一個團隊的一部分，一起工作來生產(chǎn)一些軟件。我們的團隊知道，在六個月內(nèi)，我們的最小可行產(chǎn)品(MVP)需要準備好發(fā)布。我們也知道，在最初的版本發(fā)布之后，我們的團隊將繼續(xù)對我們的產(chǎn)品進行迭代:我們將修復bug，我們將添加新特性，我們將修補安全漏洞，甚至有一天，我們可能會棄用或刪除部分產(chǎn)品。

實際上，我們的產(chǎn)品可以是任何類型的軟件，但在本文的其余部分中，我將描述的產(chǎn)品是一個設計系統(tǒng)，由許多單獨的組件組成。作為設計系統(tǒng)的生產(chǎn)者，我們將自己稱為為訂閱者維護系統(tǒng)的發(fā)布者。

項目和產(chǎn)品

在我職業(yè)生涯的大部分時間里，我都在機構從事項目工作，而這些項目大部分都圍繞著網(wǎng)站和網(wǎng)絡應用。這些項目通常都有一個結束日期，也就是啟動日期。即使當我的同事和我與其他團隊合作提供長期支持和維護時，這種類型的工作在計劃、路線圖和用戶關注方面也不同于產(chǎn)品工作。

在設計系統(tǒng)的上下文中尤其如此，其中設計系統(tǒng)團隊的角色是發(fā)布者，而受眾的角色是訂閱者。Nathan Curtis談到了從項目到產(chǎn)品思維模式的轉變，他指出，一個系統(tǒng)是“一個活的、不斷發(fā)展的、將服務于其他產(chǎn)品的產(chǎn)品的起源故事”。

對我來說，這種心態(tài)轉變的有趣之處在于，很多人——如果不是所有人的話——已經(jīng)習慣了扮演我提到的其中一個角色。不管我們是否意識到，我們都是訂閱用戶。

想想看:你最近有沒有更新安卓或iOS應用程序?你是否在公寓或家里為物聯(lián)網(wǎng)設備安裝了新版本的固件或軟件?你有升級到最新版本的Windows或MacOS嗎?我覺得很有可能是你干的祝賀您，您是軟件的一部分(或多個部分)的訂閱者。

現(xiàn)在，想一下這個的另一邊。如果您負責創(chuàng)建和維護我上面提到的某個軟件，您將如何向您的訂閱者表明您的團隊已經(jīng)在軟件中構建了新特性、修復了漏洞或修補了安全漏洞?您需要向您的訂閱者提供哪些關于您的更改的文檔?要使發(fā)布者到訂閱者的過程發(fā)生，您需要什么樣的工作流?

我在這里暗示的是一個發(fā)布策略，它由三個概念組成:為我們的整個設計系統(tǒng)或每個單獨的組件維護一個版本號方案。2. 創(chuàng)建一個變更記錄——一個變更日志——這樣我們的訂閱者就知道這個版本和上一個版本有什么不同。3.將系統(tǒng)或其組件的新更新版本發(fā)布到訂閱者可以使用它的地方。

讓我們再深入研究一下這些概念。

版本

我們的團隊在過去的六個月里努力工作，我們的MVP已經(jīng)準備好要發(fā)布給全世界了!恭喜你!我們終于發(fā)布了1.0版!但是這個版本號代表什么?它來自哪里?當我們不可避免地要對我們的產(chǎn)品進行一些更改時，下一個版本號是什么?

語義版本控制(Semantic Versioning, Semver)是一種流行的規(guī)范，我們的行業(yè)使用它來描述公共接口版本之間的變化。每個版本都直接綁定到一個版本號上，該版本號由三個用句點分隔的數(shù)字組成。這三個數(shù)字分別表示主、小和補丁(例如:3.10.2)，每個數(shù)字都有一系列有序的版本。Semver網(wǎng)站將major、minor、patch的語義差異總結如下:

給出一個版本號MAJOR.MINOR。補丁，增加:1。當你做不兼容的API更改時，主要版本2。當您以向后兼容的方式添加功能時，將使用次要版本;修正向后兼容的錯誤時的補丁版本。”

我并不打算在本文中詳盡地介紹Semver及其復雜性，但是了解major、minor和patch非常重要——尤其是在Node上下文中。因為Semver內(nèi)建在npm管理其包的方式中。檢查包。json用于我們的彈跳球項目，這是一個很好的練習，可以輕松理解項目如何管理它的包。當您查看這里列出的依賴項和devDependencies時，打開這個備忘單，看看我們的包是如何運行的。json指的是版本和范圍。

版本控制…什么?

既然我們已經(jīng)討論了版本和版本號背后的一些含義，那么讓我們來討論一下我們到底在控制什么版本。在本文的開始部分，我們設想我們的團隊正在努力為我們的設計系統(tǒng)構建組件。當我們開始我們的項目時，我們決定使用Git將我們所有的設計系統(tǒng)代碼包含在一個存儲庫中。

在開始的時候，我們的團隊需要決定它作為發(fā)布者的角色:我們的訂閱者應該如何使用我們的組件?設計系統(tǒng)應該是它自己的單一包，訂戶帶進他們的項目，批發(fā)?或者設計系統(tǒng)應該是許多可單獨訂閱的包的容器，讓我們的消費者選擇他們想要的包以及這些包何時更新?

這兩種策略都有利有弊，在我看來，大多數(shù)的利弊都是圍繞著計劃，以及出版商和訂閱者應該把他們的時間和精力花在哪里和如何上。

例如，如果您的設計系統(tǒng)作為一個單獨的包來管理和發(fā)布，您的團隊可能會發(fā)現(xiàn)開發(fā)一個發(fā)布周期是有利的——可能是每月或每季度。隨后，團隊可能會發(fā)現(xiàn)它可以預測每個版本的特性、修復和其他工作的數(shù)量。這種可預測性不僅可以幫助發(fā)布團隊，還可以幫助訂閱團隊制定計劃和路線圖。

相反，也許你的訂閱者不想更新到整個設計系統(tǒng)的最新版本——也許他們不能?？赡苡幸粋€或一組包他們無法更新，他們現(xiàn)在面臨著落后的風險，直到他們能夠優(yōu)先更新。也許，如果設計系統(tǒng)單獨發(fā)布它的軟件包，訂閱者將能夠根據(jù)他們自己的條款更新到這些更新的軟件包。

無論您的團隊選擇哪種管理策略——單個包還是多個、單獨的包——重要的是要關注您的訂閱者?？紤]一下，如果您是訂閱者，您希望如何讓更新和發(fā)布傳遞給您。想想你的訂閱者需要什么才能保持最新，想讓他們更新或遷移到你的最新版本需要什么。嘗試考慮每個更新的下游影響，無論它們是單個包還是多個包。最終，團隊的利益相關者就是它的訂閱者。

但是，不要讓這壓倒了你的團隊。安慰的事實，你的團隊是由聰明的人誰習慣于成為訂戶。鼓勵他們想想上一次在其他項目中更新Rails或npm依賴項是什么時候，以及那種體驗是什么樣的。

版本控制…如何?

我剛剛討論了哪些團隊將進行版本控制，但是我還想提到團隊如何使版本控制過程更容易、更準確。

首先，您可能知道(也可能不知道)包含許多包的存儲庫通常被稱為單一存儲庫。使用monorepo方法的一些流行項目的例子包括Babel、React、Meteor和Jest。假設我們的設計系統(tǒng)項目是由許多包(我們的組件)組成的，那么我們的設計系統(tǒng)也可以被稱為單體系統(tǒng)是有意義的。

包括我上面列出的那些流行的，單一pos傾向于分享的一個特點是，他們利用自動化來管理他們的版本號。不管你的設計管理系統(tǒng)作為一個單獨的包或盡可能多的個人包,我想我們都同意,我們的團隊應該花費時間構建驚人的組件和解決問題subscribers-not陷入困境在如何包需要撞他們的下一個版本,這些版本是什么,等等。坦白地說，不自動化這個過程聽起來像是導致混亂和最終的災難。

幸運的是，有一個名為Lerna的工具可以幫助管理使用Git和npm的單機操作流程。Lerna最初是作為管理巴別塔單礦石的工具開始的，在它被提取出來成為它自己的獨立工具之前。

Lerna將處理你的版本,但它真的照當你深究它的一些其他功能,如結合它與傳統(tǒng)致力于自動生成更新日志文件和配置注冊表自動發(fā)布你的包,這是我們將會討論接下來的兩個概念。

更新日志

我們以前討論過編寫發(fā)布說明，但是維護設計系統(tǒng)中所有組件的發(fā)布說明或更改日志對于您的訂閱者來說是非常重要的，這可能會讓人望而生畏。幸運的是，有一些工具可以為您自動執(zhí)行這個過程。

我在上面提到過，您可以使用Lerna自動生成更改日志文件，但是如果您不使用Lerna，另一個需要研究的工具是semantic-release。這個工具將自動化整個發(fā)布工作流，包括確定下一個版本號，生成發(fā)布說明，以及發(fā)布一個或多個包。

Lerna和語義發(fā)布都使用存儲庫的提交消息，不僅可以理解要執(zhí)行的版本增量的類型，還可以編譯每個發(fā)布生成的變更日志。這對于您的團隊來說是非常強大的，因為只要他們堅持傳統(tǒng)提交規(guī)范，變更日志生成的自動化過程——以及版本號的遞增——就會自行處理。剩下的惟一部分就是將最新更新和文檔化的包分發(fā)給您的訂閱者。

發(fā)布到注冊表

我們已經(jīng)增加了版本號，我們已經(jīng)創(chuàng)建了變更日志來描述我們的變更，現(xiàn)在是時候?qū)⑽覀兊陌l(fā)送到訂閱者可以獲得它們的地方了——通常稱為包注冊表。

在Node的上下文中。npm是最流行的注冊——特別是對于公開可用的節(jié)點包。GitHub現(xiàn)在擁有npm，它有自己的包注冊表，允許公有和私有發(fā)布，JFrog Artifactory也允許私有發(fā)布。

包發(fā)布是我們工作流程的另一部分，如果手工完成，可能會令人生畏。如果您認為這是我提倡自動化流程的另一種情況，那么您是對的!幸運的是，我上面提到的兩個工具，Lerna和語義發(fā)布，是為了自動發(fā)布包而構建的。

為了發(fā)布包，這兩種工具都會執(zhí)行類似的過程，以確定注冊中心中是否存在具有相應版本號的包。只有在注冊表中不存在與其對應的版本號時，包才會被發(fā)布。這可以防止您的包覆蓋自己，并防止新更改污染已經(jīng)發(fā)布的包。您的訂閱者將知道任何遞增的版本號都表明他們試圖更新的軟件包有了一些新的變化。

通過自動化釋放

作為開發(fā)人員，我們知道自動化我們的流程和工作流的好處。將設計系統(tǒng)發(fā)布后的過程自動化(管理版本號、編譯變更日志和處理包發(fā)布)可以讓您的團隊專注于真正重要的事情:通過構建和維護優(yōu)秀的軟件，成為訂閱者的優(yōu)秀合作伙伴。