我每次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更新后都被迫做作曲家更新

回答

相关问题