Git Post-receive hook与部分工作树

时间:2015-05-06 14:20:22

标签: wordpress git deployment githooks

我想使用git将网站部署到测试服务器。我的网站是一个用gulp构建的wordpress主题,存储库看起来像

theme.git/
-- gulpfile.js
-- src/
-- build/

我已按照herehere解释的步骤设置了服务器上的裸存储库,配置了git工作树的位置并编写了一个post-receive hook to结账回购到那个地方。

问题是我只想将build/文件夹移动或复制到服务器上的位置。我唯一的想法就是写一个post-receive hook将repo拉到一个工作树位置(因为我觉得我读过那个裸的repos通常都没有工作树),然后是{{1}将构建文件夹放入cp

看起来不必要的复杂,所以我想知道是否有更有效/更常见的方式去做。谢谢!

4 个答案:

答案 0 :(得分:4)

如此广泛地使用git部署的approch似乎有点奇怪,主要是因为git是主要的源代码管理系统,而不是部署工具。确实,你可以使用git hook做许多奇怪的事情,但由于某种原因,我觉得那些回归困扰你的倾向。

通常情况下,我会建议您使用某种continuous integration工具来完成工作。我可以使用的一个可能的工作流程是

  1. 将您的主题文件存储在GitHub的公共存储库中。它是免费的,你的主题源代码中可能没有什么大秘密,作为额外的奖励,你甚至可以开源你的主题。
  2. 为您的存储库设置Travis CI的CI作业。您基本上可以在云中获得免费的构建计算机实例,并且您可以在构建之前或之后执行各种操作。你可以,例如。运行gulp build(或任何你的任务名称),所以你根本不必将build目录存储在git仓库中。
  3. 在Travis after_success挂钩中,您可以将构建目录复制到目标服务器,例如使用scpHere is an example of doing the very same thing with FTP。 Travis支持encryption of sensitive data,所以你不必担心(至少那么多)在git仓库中存储用户名和密码。
  4. 当您想要在每次向git仓库提交内容时部署构建时,该流程非常有用。 BTW,当您第一次使用它时,它真的感觉像魔术一样:“我刚刚制作了这个git push,现在我的服务器上的更改已经存在。“

    但是,您提到要将代码部署到测试服务器。确实,CI工具(例如Travis)可用于维护不同部署步骤之间的流程,其中许多是测试服务器。大型项目的一个示例流程可以是

    development -> tests passing? -> release -> tests passing? -> integration -> tests passing? -> staging -> tests passing? -> production

    ...使用CI工具可以部分或完全自动化流程。

    然而你的声音听起来像是在你的情况下部署构建是一种一次性的事情,你有时只想手动做。(如果我误解你,我道歉。)对于这些一次性任务,使用shell脚本或任务管理工具更合适。

    您提到您已使用gulp。这对于这项工作来说非常方便,特别是因为您可以轻松地组合不同的“任务流”。您可以有一个用于构建主题的任务(gulp build)和另一个用于测试服务器部署的任务(gulp deploy-test),它只是扩展了build任务,还有一个步骤,用于将文件复制到测试服务器。 gulp-scp看起来像是一个很好的任务插件(虽然我自己没有使用它,但它只是谷歌的第一个搜索结果)。如果无效,您可以随时使用gulp-shell或类似方式致电scp

    你甚至可以parametrize the deployment tasks所以你可以这样做: gulp deploy --testgulp deploy --production

    你去了,这是你在devops的第一课。如果软件项目中的这种任务自动化听起来对您有意义,那么整个世界都需要学习。

答案 1 :(得分:3)

这是直截了当的#!/bin/sh while read old new ref; do [[ $ref = refs/heads/master ]] && { export GIT_INDEX_FILE=deployment-manifest export GIT_WORK_TREE=/path/to/deployment git read-tree -um `git write-tree` $new:build || exit 1 }; done 工作。为部署目录中的内容保留一个清单aka索引,并使用预先接收处理您的更新,如下所示:

git read-tree

注意 如果在部署树中更改了以这种方式部署的某个文件,则sed '/^>/s/.//11g' file 此处和推送将失败,因为git赢了&# 39; t覆盖你还没有告诉过的内容。

答案 2 :(得分:0)

我会把你的项目分成两个回购。

  1. 源。包括来源等等。排除/ build /目录。仅用于源代码管理。这永远不会进入网站(将代码存储在网站上可能不安全,即使是以git repo的形式存在)。

  2. 部署。只有/ build /目录。您可以在目录中启动新的git repo。这在服务器上有一个远程仓库;您可以像以前一样使用post-receive hook进行部署。

答案 3 :(得分:0)

我一直使用git进行部署。根本没什么奇怪的,我也不知道@cido对它的反应。能够及时回到“部署”中的任何一点,都具有很大的价值。分支,并能够准确地看到当时服务器上的内容。

请勿将您用于存储的git repo与您用于部署的git repo混淆。你应该有一个完全干净的git树签出到你的生产区域(无论是什么),正如我所建议你可能想要一个名为“部署”的单独分支。或者'生产'或者'分期'或者其他什么。

您的post-receive挂钩只需要运行一个进入生产区域的脚本,然后拉出您的部署分支进行更新。

如果您需要这样做以防止文件被置于git之外的文件(例如在运行时生成的临时文件),那么您可能需要在拉动之前调用git clean -dfx。如果您希望定期从头开始重建此服务器(例如在云部署中),您可能还想做其他事情,但听起来手动进行初始设置应该可以。用例。

cp构建目录到位听起来不错,只有我使用rsync,因为如果更改只是增量的话,它通常会更快。