使用 Satis 搭建私有仓库

现在我们常用 Composer 进行依赖管理。和其它语言的包管理工具一样，Composer 使用 GitHub 托管代码，可以根据配置文件管理依赖，也可以建立各种脚本，执行特定任务。总之好处很多。

实际工作中，我们可以把多个项目公用的逻辑抽出来，作为一个依赖，然后提交到 Packagist，就可以在其它项目中引用它了。但是，与 NPM 这种工具不同的是，PHP 程序多半会部署在服务器上，通过接口接受外部访问，对安全性的要求高很多。前端可以放开给大家随便观摩，后端最好还是放在别人轻易看不到的地方，万一哪个同事把密码、salt 写到代码里提交，被搜出来，结果可能就很危险。

此时我们就需要一个工具，能够搭建私有源，里面都是私有仓库，对内不对外。

Satis 就是 Composer 官方提供的建立私有源的工具。它的文档在这里 以及 这里。

整体流程并不复杂，文档里都有，我简单复述一下，只包含我用过的部分，重点穿插我的经验。我假定读者已经了解 Composer 的基础使用，如有问题，请自行翻阅文档。

1. 建立项目

使用 Composer 自带的建项目功能，这个相当于 git clone + composer install + 运行 post-install 脚本。

composer create-project composer/satis my-satis --stability=dev --keep-vcs

2. 建立配置文件

在 /path/to/my-satis 目录下建立 satis.json 文件

{
  "name": "仓库名称",
  "homepage": "http://satis仓库地址",
  "repositories": [
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo" },
    { "type": "vcs", "url": "http://svn.example.org/private/repo" },
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo2" }
  ],
  "require-all": true
}

注意：仓库名称需要和仓库里 composer.json 的 name 定义一致，和路径没什么关系，不然就会找不到。我当时被这个卡了好久……

因为加入私有源的仓库本身可能也有依赖，require-all 会把这些依赖的信息也抓进来。如果不需要的话，可以指定某个仓库，甚至某个版本：

{
  "name": "仓库名称",
  "homepage": "http://satis仓库地址/",
  "repositories": [
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo" },
    { "type": "vcs", "url": "http://svn.example.org/private/repo" },
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo2" }
  ],
  "require": {
    "company/package": "*",
    "company/package2": "*",
    "company/package3": "2.0.0"
  }
}

3. 生成仓库列表

执行

php bin/satis build satis.json ./web

就可以在 path/to/my-satis/web/ 里生成仓库列表了。

4. 在其它项目中使用私有源

只需要在项目的 composer.json 文件的根上添加

{
  "repositories": [
    {
      "type": "composer",
      "url": "http://satis仓库地址/"
    }
  ],
  "require": {
    "company/package": "1.2.0",
    "company/package2": "1.5.2",
    "company/package3": "dev-master"
  }
}

之后再通过 composer require 或者 composer install 想要的仓库就可以了。

注意：源里面只有“仓库列表”，并没有真的同步代码仓库过来，所以下载还要走托管代码的机器，比如 GitHub，内部 GitLab 等。所以需要确保相关的 ssh-key 已经添加，或者在配置文件中写上登录信息（不建议这么做）。

Tips: secure-http

satis 默认要求使用 https，不过 https 需要证书，不太好搞，比如前司运维就不愿意弄（当然，他们工作很忙，我十分理解）。此时我们可以设置 secure-http 为 false 强制 Composer 接受 http 的源。需要注意，secure-http 是 config 的属性之一，写在根上是没用的。

{
  "config": {
    "secure-http": false
  }
}

---

总结，Satis 私有源的搭建，对于使用 PHP 的开发团队来说是非常必要的。用 Composer 管理依赖效果也非常好，希望所有 PHP 开发者都好好学一学。我现在用的也比较浅，将来有心得继续补充。

---

题外话

再聊一些题外话。PHP 是个很好的语言，简洁高效，易学强大。但是出身不好，工程学上的高起点反而成为大家轻视它的原因。很多开发者也的确对自己要求不高，只写业务逻辑不考虑语言特性，使得代码难看难改难维护。所以我想多说两句回顾一下 PHP 本身的发展史。（以下以我个人经历为主）

上古时期

我们一个页面写一段 PHP，或者一个动作写一个 PHP，收集请求，做出处理，给出回应，完成。

好处：

1. 简单，好上手

2. 逻辑关系清晰，从前端可以直接找到目标程序

3. 一个地方出错，多半只挂一个功能

坏处：

1. 代码复用率低，不好维护

2. 难以批量修改

古典社会

随着工程变大，需要大量的 PHP，分散碎片化的代码实在难以管理和维护。于是我们开始把一些共用代码抽出来，做成一个函数，叫 functions.php，其他所有页面都 include 它，这样公用的代码就不会这里一份那里一份了。

好处：

1. 提高了代码复用性，减少开发量，提升效率，降低维护难度

坏处：

1. 工程大的话，一个 functions.php 好几千行，可读性也没好到哪儿去

2. 有时候我们需要对一个函数进行一些小修改，于是不仅函数库会膨胀，函数本身也在膨胀

中世纪

PHP 引入类的概念，并且提供了“魔术方法”来实现一些功能。有些程序员也意识到不能所有代码都自己手写，该引用的还得引用，于是从一些开源的库拷来代码开始用。这个时候连 Google Code 都不存在，下载代码多半在网上搜索 + Ctrl C/V，所以代码中各种混用。经常出现，我 include 一个文件，然后就挂了，原来是类被重复定义，或者全局环境下同名函数互相覆盖。开发乱象不断，形如黑暗的中世纪。

好处：

1. 不考虑维护的话，开发速度还是可以的……

坏处：

1. 越到后来坑越多，项目一大积重难返

2. 内部执行环境不统一，a.php b.php 的内部环境都不一致，共享代码反而更加困难

文艺复兴

PHP 对类的支持已经十分完善了，大家也开始习惯用命名空间划分领域。通过使用设计模式、继承、接口，复写功能和代码管理的情况大大改善。同时，伴随 Google Code 和 GitHub 的出现和发展，大家有了一个托管代码和寻找代码的好地方。我们也开始用 SVN 管理代码，不会再搞出 action.php action.php.bak action_new.php action_new.20160102.php 这样的幺蛾子。开始学习开发规范，开始更多的的用类管理代码。

好处：

1. 代码规范

2. 版本管理后，更好追溯代码的变更记录

3. 可以下载到新版本的代码

坏处：

1. SVN 不方便进行多仓库的管理

2. 测试还靠人工发掘问题

近代社会

Git 开始普及，我们可以更方便的管理代码了。GitHub 发展速度很快，从上面找好代码也很容易，凭借 Git 子仓库的概念，维护依赖也容易很多。MVC 框架开始普及，单入口开始流行，内部执行环境得到统一。开发者意识到测试的重要性，开始使用测试工具进行测试开发，代码的稳定性进一步提升。

好处：

1. 内部执行环境统一，全局修改变得容易

2. 开始写测试了

坏处：

1. 学习成本开始增加，新入行的人开始搞不懂，为啥写一个脚本就能干的事，你们要搞这么复杂一套架构出来

现代社会

包管理工具成为标配。项目依赖不再通过复制代码或者子仓库来管理，而是直接使用包管理工具 Compposer。并且整合测试、部署脚本，方便我们更容易地完成整套开发流程。另一方面，前端之前已经崛起，PHP 可以更多的考虑后端业务逻辑，输出纯粹的数据接口。

好处：

1. 大型项目稳定性可用性大大增加

2. 专业分工加强，PHP 程序员可以更多考虑后端逻辑

坏处：

1. 学习曲线更加陡峭，新人入行更难，甚至连有经验的老人都未必能适应新形态的开发。

---

然则历史的车轮不可阻挡，我们势必会走向学习成本更高、学习曲线更陡，但业务量更大、更稳定的未来。

与我的博客同步更新。