程式設計師做完整性檢查的命令列工具
同個專案在不同的機器上加入協力(Solidarity)工具就不用操心了
同事或客戶要拿最新版本的程式碼，就為了這個目的把自己的程式碼推送了上去。然後悲劇傳來 ?，用不了。這種情況大家碰到過多少次了？
要找出問題，既討人厭又費時間，總是給人壓力。這一來說明專案不牢靠，折磨人；二來這種頭疼的事情很常見，卻很難事先考慮到。當然，最後找的問題卻總是很容易解決，而且本該能預防的。我們需要的只是一個良好的預防措施！這就是為什麼我們製作了這個開源軟體叫協力(Solidarity)，免費又好用。
協力(Solidarity)是一個命令列工具。一個專案的執行環境應該是怎麼樣的？實際執行環境又如何？這個工具能比對兩者，在實際執行環境裡進行檢查，發現有部分缺失時發出警告。
多個電腦上檢查執行環境中專案所需的依存關係。
設想一下這個情景：
Betty把最新的程式碼抓取了下來，卻發現在她的機器上用不了。你就要她執行命令$ yarn solidarity，檢查執行結果是否有問題。她回報說命令失敗，因為發現她的電腦裡缺少某個必要的二進位制檔案。不過後來她裝好了，於是這個專案執行?通過，大家都高興。
那就是協力(Solidarity)的作用。開發環境中各類工具越來越多，而協力(Solidarity)能有助於鎖定專案所必需的工具。
協力(Solidarity)是一個完美的工具。它確保整個團隊既能共用同一個複雜的開發環境，又不用擔心環境到底有多複雜。
看看它如何執行——讓我們把它新增到一個專案裡去：
協力(Solidarity)本身與具體專案無關，可以執行在任何專案裡，所以應用到具體例子裡時，儘量不要把思路侷限在它本身上。在這個例子裡，我要把協力(Solidarity)加到一個React Native專案裡去，這種專案往往包含了數不清的部件，很靈活。另外我們還可以用到已有的協力(Solidarity)快照功能。
我們先暫時不做全域性安裝，只利用單個專案的node_modules資料夾。一開始先裝兩個東西：協力(Solidarity)工具和React Nativer的協力(Solidarity)快照外掛。
$ yarn add solidarity solidarity-react-native --dev
現在只要打一個命令，就可以給React Native專案中的重要部分拍快照了。
$ yarn solidarity snapshot這樣就行了！
從這裡開始，系統會詳細說明每一步，會有下面的互動：
- 因為沒有
.solidarity檔案，系統會提示要建立一個新檔案 - 系統會問需要用哪個外掛來給環境規則拍快照
我們要用剛裝的React Native外掛。整個過程看起來是這樣的：
性感火辣的自動快照?
這樣就在.solidarity檔案裡生成儲存了所有的環境規則，以及系統裡已安裝的與React Native相關模組版本。現在如果執行一次協力(Solidarity)檢查，就能成功通過！但是，在其它電腦上行不行呢？
用版本控制軟體把.solidarity檔案提交進去，然後就可以把yarn solidarity命令新增到像產品釋出用的主機、持續整合用的主機或別的什麼電腦上去了。就是那麼簡單！
如果我用的技術棧不能“快照”呢？
自己寫個外掛容不容易？非常容易，但真的沒必要。我們可以手動把規則寫進一個JSON檔案裡，就跟把開發環境中的各方面列成表一樣簡單。
只要開啟一個.solidarity檔案，它的結構看起來是一個開啟的物件，裡面每個鍵都表示一個需求，每個值都代表實現那個需求的規則！
這裡隨便寫了幾個需求的例子，只要是開發人員都能讀得懂：
{
"requirements": {
"Node": [{ "rule": "cli", "binary": "node", "semver": "~8.5.0"}],
"Watchman": [
{
"rule": "cli",
"binary": "watchman",
"error": "install watchman `brew install watchman`",
"platform": "darwin"
}
],
"Optimize Service": [
{ "rule": "cli", "binary": "imageOptim" },
{ "rule": "env", "variable": "OUTPUT_DIR" }
]
}
}.solidarity檔案只不過是一個簡單的JSON檔案。上面這個檔案裡有三個需求：節點(Node)、看護(Watchman)和優化服務(Optimize Service)。
- 節點(Node)：檢查某個版本的二進位制檔案是否安裝好了
- 看護(Watchman)：檢查某個二進位制檔案，不管什麼版本。但只針對蘋果作業系統。為使用者著想，我們甚至還放了一個友情提示。
- 優化服務(Optimize Service)：由兩條規則組成。一條檢查命令列介面是否存在，另一條檢查某環境變數是否設好。
寫規則：你們要用的規則和例子裡的類似嗎？是的話就太扯了。但我隱約覺得大家已經知道有哪些環境問題要檢查了。可能是某個安卓軟體開發套件，或是一個每次都少掉的環境變數？這裡有文件，看看哪些部分可以用規則檢查：https://github.com/infinitered/solidarity/blob/master/docs/options.md
寫外掛：一套規則一旦寫完，一個外掛其實已經完成８０％了。看一下如何將檔案轉換成外掛，也可以分享給別人：https://github.com/infinitered/solidarity/blob/master/docs/plugins.md
自定義規則的做法就是這樣！所有的資訊都在文件網站上，看這裡。
為什麼不直接用容器？
準確地說，正好存在兩種情況使容器很難實施。我們提供軟體諮詢，參與開源軟體開發，所以想在自己單位外部的組織裡施加複雜的容器是不切實際的。而協力(Solidarity)做的是“輕量型環境檢測”，原因就是我們專案中的引導和遷移這兩大流程必須保持精簡併容易擴充套件。還有一個加分項：只加一個小小的依存關係，而又專注於手頭上正在做的專案任務，做到這一點很容易。
協力(Solidarity)為開發環境進行檔案鎖定。幫助我們完善它吧！
- 給這個軟體倉庫打星號並分享：https://github.com/infinitered/協力(Solidarity)
- 把它加到專案裡去，不再操心
- 覺得合適，就把自己做的外掛釋出出來
- 喜歡這篇文章嗎？按幾下拍手按鈕來謝謝作者。
- 加入我們的Slack頻道提問或聊天：http://community.infinite.red/
鳴謝
- Steve Kellock ——Gluegun工具的作者，為創作solidarity提供了靈感
- Jamon Holmgren——對 Gluegun最近的美化作出了極大的貢獻
- Kevin VanGelder——幫助solidarity能?%在Windows上執行
- Hacktoberfest上那些現身並幫助本專案的廣大群眾！