spidgorny / migrate
使用 Mercurial 和 ssh 进行部署和迁移
Requires
- kevinlebrun/colors.php: dev-master
Requires (Dev)
- atoum/atoum: ^2.8
This package is auto-updated.
Last update: 2024-09-17 00:41:23 UTC
README
migrate
一个 PHP 脚本,用于处理使用 Mercurial 进行版本控制的迁移项目及其依赖的 Mercurial 仓库的版本。
如果你使用 git - 你不需要再往下看了。
如果你使用 composer 来管理依赖项的分支版本 - 你也不需要再往下看了。如果你在 Mercurial 中不使用分支,请继续阅读。
快速开始
> migrate add . > migrate add vendor/spidgorny/nadlib > migrate add vendor/something/else > hg add VERSION.json > migrate commit "update VERSION.json" > cd /directory/corresponding/to/the/live/server > rem Start synchronization tool (read below) > migrate golive ...........
简介
当测试 deployer 部署我的 PHP 应用程序时,我意识到它旨在与 Git 一起使用。它不适用于 Mercurial (hg)。这促使我为自己跟踪在 Mercurial 中的项目编写了部署脚本。
部署的一般目的
migrate 尝试解决两个独立的问题。一个是能够将文件上传到远程机器。这本身就是裸部署。另一个问题是知道要部署的确切项目版本及其依赖库版本,以及上次部署到在线服务器上的版本。
在 migrate 中通过在 VERSION.json 文件中存储必要的版本来解决此问题。VERSION.json 文件中有一些用于管理仓库的命令。如果知道自己在做什么,也可以手动编辑此文件。
管理 VERSION.json 中的仓库
add
将指定的文件夹(默认为 .)添加到 VERSION.json 文件中。确保至少添加主项目作为 "."。
> migrate add .
del
从 VERSION.json 文件中删除指定的文件夹(无默认)。
compare
显示当前的 VERSION.json 和当前安装的版本。
dump
仅显示现在存储在 VERSION.json 中的内容。如果没有参数调用 migrate,这是默认命令。
部署策略
使用 migrate 进行部署有两种方式。一种方式是在 PC 的本地文件夹上运行命令,并依赖于一些第三方同步工具将本地文件中做出的更改复制到远程服务器。这些工具包括
- PhpStorm
- WinSCP
- FileZilla
另一种方式是直接在在线服务器上运行 Mercurial 和 composer 命令,以便服务器从仓库中拉取更改。这需要服务器上的 SSH 访问和 PC 上安装的 SSH 客户端。还需要对服务器进行公钥认证,否则您将不得不频繁输入密码。至少对于每个命令至少一次。
使用外部同步进行部署
运行这些命令时,您将切换到与在线服务器状态相对应的本地文件夹,并在后台运行同步工具。这些命令将仅更改本地文件的内容。对在线服务器所做的所有更改都取决于同步工具(例如 PhpStorm)。
这不再推荐。如果您有权访问在线服务器的 SSH,请检查使用远程 hg 命令的部署。
install
在各个仓库上运行 "hg pull" 和 "hg update -r xxx"。
composer
运行 composer install。
golive
检查当前版本,安装新版本,composer(在 LIVE 上调用)。
info
显示当前文件夹的默认拉取/推送位置。允许比较当前和最新版本。
update
获取最新版本并更新。与 install 类似,但仅针对主文件夹仓库(.)。
check
对VERSION.json中的每个仓库运行 "hg id"。这将替换VERSION.json。
Mercurial命令
由于我们在VERSION.json文件中存储了依赖的仓库,我们可以对特定仓库运行一些Mercurial命令,而无需手动进入该目录。并且我们可以自动逐个运行所有跟踪的仓库的这些命令。
您可以通过只输入部分仓库路径来指定每个命令应在哪个仓库上运行。
> migrate thg nadlib
这将运行"nadlib"匹配路径部分命令在vendor\spidgorny\nadlib路径。
thg
将在指定文件夹(使用.)中执行TortoiseHG。部分匹配有效。
changelog
显示主项目的人读日志。
push
仅执行 "hg pull",没有任何更新。
pull
仅执行 "hg pull",没有任何更新。
commit
将提交VERSION.json文件并推送。
dump
仅显示当前VERSION.json中存储的内容。
check
对VERSION.json中的每个仓库运行 "hg id"。这将替换VERSION.json。这通常在运行其他命令之前调用,以便了解仓库的当前状态。
使用远程HG命令部署
这是 migrate 最好的部分。在继续之前 - 确保你可以运行
> ssh live.server.com -i your/public/key.file
而不输入您的密码。以下所有命令都运行ssh命令,就像上面一样 + 在连接到它之后在实时服务器上指定要执行的操作。
另一个概念是在子文件夹中进行版本控制。Migrate将自动在实时服务器上创建一个子文件夹,对应于mercurial仓库中项目的修订号。如何更改您的Apache配置以指向新位置或使用RewriteRule动态路由用户请求到相应的子文件夹由您自己决定。
实时服务器名称,实时服务器
mkdir
将ssh到实时服务器并创建当前版本的子文件夹。
###rls 将连接到实时服务器并运行ls -l。
###rclone 将连接到实时服务器并克隆当前仓库。
###rstatus 远程运行hg status
rpull 在服务器上拉取 rupdate 仅更新服务器上的主项目。不推荐。请使用rinstall。rinstall 将更新到服务器上VERSION.json的精确版本。逐个更新所有仓库。请确保首先运行rpull()。rcomposer 在远程运行composer rdeploy 在新文件夹中创建,克隆,将其组合或更新现有rvendor 尝试rcp vendor文件夹。由于rcp不使用id_rsa?dump 仅显示当前VERSION.json中存储的内容 check 对VERSION.json中的每个仓库运行 "hg id"。这将替换VERSION.json