使用 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. 学习曲线更加陡峭，新人入行更难，甚至连有经验的老人都未必能适应新形态的开发。

---

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

与个人博客同步更新。