我每次svn更新後都被迫做作曲家更新

如何解決一個問題，當使用laravel框架在同一個項目上工作的幾個開發人員有不同的本地laravel/vendor/composer/*文件？我每次svn更新後都被迫做作曲家更新

想象一下，我們有一臺生產服務器，我們不再運行作曲家（或者我們會？）。要將所有文件投入生產，開發人員必須在本地執行composer update，因此laravel會動態創建/更改文件，例如文件夾vendor/composer/中的文件。比開發人員提交這些文件到生產和它的工作。

但在我的同事提交後，我想更新我的svn。這意味着它也將更新動態創建的文件，這將錯過例如我目前的工作變化。所以我必須在我的本地實例上自己運行作曲者更新以實現同事的更改，並且還包含我當前的（尚未提交的）更改。

這是一個正常的良好做法，每次svn更新後總是在localhost上運行composer update？

來源

2014-08-27 ulkas

很多問題，但我想我明白你的問題是什麼。

首先確保您沒有控制供應商目錄版本。 composer.json和composer.lock都應該受版本控制。

如果有人已經通過作曲家安裝了一個新軟件包，所有其他開發者在獲得新代碼後都應該執行「作曲家安裝」。

在生產中你總是運行「作曲家安裝」，從來沒有「作曲家更新」。

「Composer更新」應該以受控的方式運行，因爲它的作用是使用新版本更新所有軟件包（根據composer.json設置）。

來源

2014-08-27 11:54:54

好吧，運行中的作曲家是不是安全風險？據我所知 - 1：有時通過純http下載軟件包。2：我將不得不手動檢查下載的供應商軟件包的生產情況，不管它們是否包含惡意軟件（例如存儲庫本身可能同時遭到破壞）。我寧願先在我的本地主機上進行檢查，然後將檢查過的供應商包文件放在生產 – ulkas 2014-08-27 12:29:02

上，其次，我想知道，這是否是laravel框架的正常良好實踐，每次有同事確實提交新控制器類，並且我更新我的存儲庫，之後我必須運行（但不總是）'composer install'？ – ulkas 2014-08-27 12:30:33

我不認爲它應該被視爲有風險。如果你這樣做，你需要手動上傳供應商目錄，但你不應該在版本控制。如果你總是做作曲家安裝，你會得到與你本地相同的版本，所以你可以在你的本地環境中查看東西。 – 2014-08-27 12:35:26

想象一下，我們有一臺生產服務器，我們不再運行作曲家（或我們？）。

你應該運行在生產服務器上的以下部署新代碼：

php artisan down 
git pull origin master 
composer install 
php artisan migrate 
php artisan up

你應該有「composer.lock」包含在你的版本控制，讓所有開發者（和生產服務器）正在使用相同版本的/供應商文件

未運行作曲家在生產上的安全風險？

絕對不是 - 這是標準做法（假設你有composer.lock）。 Composer.lock確保您的服務器獲得完全相同的文件。如果你看裏面composer.lock，你會看到的項目，如

"url": "https://api.github.com/repos/briannesbitt/Carbon/zipball/cde7a00d1410a17fb6d61b993cb017a78be1137c",

如果milcious人是添加軟件包的新版本，它不會有相同的散列zipball位置 - 所以你仍然會收到您所期望的正確版本。

來源

2014-09-15 04:09:04 Laurence

thx爲您的答案。你能建議如何進行'顛覆'？每個'svn update'之後幾乎所有的開發者都必須運行'composer install'？ – ulkas 2014-09-16 07:38:32

我每次svn更新後都被迫做作曲家更新

回答

相關問題