使用 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. 學習曲線更加陡峭，新人入行更難，甚至連有經驗的老人都未必能適應新形態的開發。

---

然則歷史的車輪不可阻擋，咱們勢必會走向學習成本更高、學習曲線更陡，但業務量更大、更穩定的將來。

與個人博客同步更新。