Deployer-3-配置-Configuration

要设置一个配置参数，使用 set 函数，要在 task 内部获取该参数，使用 get 函数。
	set('param', 'value');
	task('deploy', function(){
		$param = get('param');
	});

对于每个主机，每个参数都可以被覆盖：
	host(...)
		->set('param', 'value');

配置参数也可以被指定为 callback 函数，该函数会在远程主机的第一次 get 调用时被执行：
	set('current_path', function(){
		return run('pwd');
	});

我们可以在 run 内部调用 {{ }} 来使用参数的值，而不是像下面这样做：
	run('cd ' . get('release_path') . ' && command');

我们可以这样做：
	run('cd {{release_path}} && command');

常见配方附带了下面列出的一些预定义配置参数。

要获取可用的参数列表，运行：
	dep config:dump

显示当前部署的发布版本：
	dep config:current

显示 inventory(主机清单)：
	dep config:hosts

下面是常见变量的列表。

deploy_path
	在远程主机上，要部署应用程序的目录。我们应该为所有主机定义此变量。例如，如果要将应用程序部署到家目录：
		host(...)
			->set('deploy_path', '~/project');

hostname
	当前主机名。通过 host 函数自动设置

user
	当前用户名。默认是当前 git 用户名：
		set('user', function(){
			return runLocally('git config --get user.name');
		});

	我们可以在 deploy.php 中覆盖它，例如使用 env 变量：	
		set('user', function(){
			return getenv('DEP_USER');
		});

	user 参数可以用于配置系统通知：
		set('slack_text', '{{ user }} deploying {{ branch }} to {{ hostname }}');

release_path
	当前发布版本目录的全路径。非部署上下文中的当前目录路径。使用它来作为我们构建的工作路径：
		task('build', function(){
			cd('{{release_path}}');
		});

	默认情况下，对于简单任务，工作路径就是 release_path：
		task('build', 'webpack -p');

previous_release
	指向之前发布版本，如果存在。否则变量不存在。
		task('npm', function () {
		    if (has('previous_release')) {
		        run('cp -R {{ previous_release }}/node_modules {{ release_path }}/node_modules');
		    }

		    run('cd {{ release_path }} && npm install');
		});

ssh_multiplexing
	使用 ssh multiplexing(https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing) 来加速本地 ssh 客户端。
		set('ssh_multiplexing', true);

default_stage
	如果主机声明定义了应用环境(stage)，该选项允许我们选择，运行 dep deploy 时，要部署的默认应用环境。
		set('default_stage', 'prod');
		host(...)
			->stage('prod');

	如果我们需要一些更加复杂的方式来决定默认的应用环境，也可以将参数设置为 callable(可调用)。

	在 set() 函数中使用 callable，允许我们在声明时不设置参数的值，只有之后调用时，才会设置值。这与分配一个简单的字符串没有区别。但是当我们分配一个函数的值时，如果不作为 callable 使用，则会立刻调用函数。作为 callable，可以在使用时才调用它，因此，用户可以使用自己的函数来覆盖，这个决定变量的函数。这是在 set() 函数中，使用 callable ，而非直接函数调用的强大优势。

	示例1：在 set() 中直接函数赋值
		让我们假设，我们必须在 'default_stage' 配置中，包含一些第三方配方，如下：
			set('default_stage', \ThirdPartyVendor\getDefaultStage());

		并且，我们想要在 deploy.php 中使用我们自己的值来覆盖它：
			set('default_stage', \MyVendor\getDefaultStage());

		第三方配方应该避免直接的函数调用，因为即使我们使用自己的 set('default_stage'，\MyVendor\getDefaultStage()) 来覆盖它，它也总是会被调用。看下一个示例，在这种情况下，第三方配方应该如何使用 callable。

	示例2：在 set() 中 callable 赋值
		让我们假设，我们必须在 'default_stage' 配置中，包含一些第三方配方，如下：
			set('default_stage', function() {
			    return \ThirdPartyVendor\getDefaultStage();
			});

		并且，我们想要在我们的 deploy.php 中覆盖它：
			set('default_stage', function() {
			    return \MyVendor\getDefaultStage();
			});

		结果是只运行 \MyVendor\getDefaultStage()。

keep_releases
	要保留的发布版本数量。-1 表示无限制。默认是 5。	

repository
	应用程序的 git 仓库。

	要使用一个私有仓库，我们需要在我们的主机上生成一个 SSH-key，并且将它添加到仓库中，作为一个 Deploy Key(也叫做 Access Key)。该 key 允许我们的主机拉取代码。或者可以使用代理转发。

	注意，主机第一次连接时，会询问将主机添加到 known_hosts 文件中。实现这个，最简单的方法是，在我们的主机上运行 git clone ，并在提示时输入 yes。

git_tty
	为 git clone 命令分配 TTY。默认为 false。这允许我们输入秘钥的密码或将主机添加到 known_hosts。
		set('git_tty', true);

git_recursive
	为 git clone 设置 --recursive 标志。默认为 true。设置为 false，将阻止子模块的克隆。
		set('git_recursive', false);

	git --recursive 的相关介绍查看：https://git-scm.com/book/zh/v2/Git-工具-子模块

branch
	分支部署。

	如果我们想要部署一个指定的 tag 或 revision，我们可以在运行 dep 部署命令时，使用 --tag 和 --revision 选项。
		dep deploy --tag="v0.1"
		dep deploy --revision="5daefb59edbaa75"

	注意：tag 比 branch 具有更高的优先级，但是比 revision 优先级低

shared_dirs
	共享目录列表
		set('shared_dirs', [
			'logs',
			'var',
			...
		]);

shared_files
	共享文件列表

copy_dirs
	发布版本之间要复制的文件列表

writable_dirs
	web 服务器必须具有写入权限的目录列表

writable_mode
	写入模式
		acl - 使用 setfacl 来改变目录的 ACL 权限(默认)
		chmod - 使用 unix 的 chmod 命令
		chown - 使用 unix 的 chown 命令
		chgrp - 使用 unix 的 chgrp 命令

writable_use_sudo
	是否使用 sudo 来执行写入命令。默认是 false

writable_chmod_mode
	writable_mode 设置为 chmod 时，默认的 mode。默认是 0755

writable_chmod_recursive
	是否以递归方式设置目录的 chmod。默认是 true

http_user
	运行 Web 服务器的用户。如果没有配置该参数，则 deployer 尝试从进程列表中检测它

clear_paths
	更新代码后，在发布版本中需要删除的路径列表

clear_use_sudo
	执行 clear_paths 时，是否使用 sudo 命令。默认是 false

cleanup_use_sudo
	执行 cleanup 任务时，是否使用 sudo 命令。默认是 false

use_relative_symlink
	是否使用相对符号链接。默认情况下，deployer 会检测系统是否支持相对符号链接，并使用它们。

	如果系统支持，默认会使用相对符号链接

use_atomic_symlink
	是否使用 atomic(原子) 符号链接。默认情况下，deployer 会检测系统是否支持原子符号链接，并使用它们。

	如果系统支持，默认会使用原子符号链接

composer_action
	composer 行为。默认是 install

composer_options
	composer 选项

env
	环境变量数组
		set('env', [
			'VARIABLE' => 'value',
		]);

查看更多关于 '任务定义' 的信息(https://deployer.org/docs/tasks)