PHP 教程：Composer 最佳實踐
概述
Composer 是 PHP 應用程式的依賴管理器，最初發佈於大約 8 年前，2012 年 3 月。
在 php 中使用 Composer 可以提高程式碼的可重用性，並使你的項目能夠輕鬆地集成來自Packagist（主要的 PHPComposer 庫）的 PHP 庫。今天，我們將重點介紹幾個部署最佳實踐。
Composer 可能會變慢
這篇文章將關注如何讓 Composer 速度更快，並在每次部署應用程式時不再需要使用全新的 Composer 安裝來安裝軟體包。
Magento 是一個需要大量記憶體的 composer 項目的例子。如果你需要為每個部署安裝 Composer，你能想像需要多少記憶體嗎？Composer 可能會因為記憶體不足而失敗，如Stack Overflow 帖子所述。
儘管將包添加到你的項目中很容易，但在 Amezmo 這裡，我們採用保守的方法添加新的項目依賴項，原因如下。
- 減慢初始 Composer 安裝速度
- 每個 Composer 包都會增加新安全問題的可能性
最佳做法
–no-ansi
此標誌禁用 ANSI 輸出，這意味著彩色輸出將被禁用。彩色輸出，如綠色和紅色字體顏色以及人眼喜歡的背景顏色。這對於我們手動運行 Composer 時非常有用，但是對於自動部署，我們不想用奇怪的字元擾亂我們的日誌文件。
–no-interaction
同樣，在自動化部署的環境中，我們不希望部署在等待輸入時停滯不前。此標誌阻止 Composer 要求用戶輸入。
–optimize-autoloader
此標誌告訴 Composer 將生成的程式碼自動載入。autoloader 是當你的入口點確實需要 ‘vendor/autoload.php’ 時調用的；
–no-progress
由於進度報告使用特殊的終端 ANSI 程式碼，因此我們不希望報告進度，因為它會使我們的日誌文件混亂。在進行非互動式
部署和 composer 安裝時，這是完全沒有必要的。
–no-dev
這一點至關重要。我們從不希望將開發包安裝到生產伺服器上。像 phpunit 和其他不應讓其投入生產的軟體包被視為 「dev」軟體包。它們在 composer.json 文件中的 「require-dev」 屬性下具有特殊條目。
–profile
這個是可選的，但是我總是喜歡包含它，因為它顯示了 Composer 用於安裝單個依賴項的記憶體量。
如何在部署時快取 Composer 程式包
現在，我們已經定義了生產級 composer 安裝命令，讓我們簡單地介紹一下在部署時使 Composer 更快的方法。
步驟 1。
在你的 Webroot 之外的某個地方創建一個全局 Composer vendor 目錄，當然該目錄不能公開訪問。
注意：Amezmo 使用如下所示的根目錄布局，因此我們將在下面的 bash 命令中使用它。當然，你可以用自己的目錄替換
這些目錄，並且可以實現所需的結果。
/webroot
|----logs
|----vendor
|----storage
|----current -> /webroot/release/${TIMESTAMP}.${COMMIT_ID}
|----release
|-------${TIMESTAMP}.${COMMIT_ID}
|-------${TIMESTAMP}.${COMMIT_ID/webroot/vendor 是我們的全局軟體包目錄，將從中為每個版本創建鏈接。
運行以下命令從 release 目錄創建的 vendor 目錄鏈接到全局 vendor 目錄。每次部署時都必須執行此操作，並且在從發行目錄運行 composer 安裝之前。
ln -sT /webroot/vendor webroot/release/${TIMESTAMP}.${COMMIT_ID}/vendor請注意，從 release 目錄運行 composer install 之前，運行上述命令至關重要。以下是步驟：
- 應該創建 release 目錄
- 運行 Git 獲取源程式碼
- 執行以上命令
- 最後運行 composer install
按照上述順序完成所有操作後，你的軟體包將被 「快取」 到 /webroot/vendor 目錄中，並且每次部署應用程式時都不需要重新安裝軟體包。
結論
- 定義了一個 Composer 命令，該命令消除了所有不必要的功能。
- 重點介紹了在部署時快取 Composer 軟體包的最佳實踐部署模式。
第 1 步。
在 Webroot 完全不在的地方創建一個全局 Composer 供應商目錄，並（此段落重複，應刪除）
