程序员做完整性检查的命令行工具

同个项目在不同的机器上加入协力(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上那些现身并帮助本项目的广大群众！