Git Post-receive hook與部分工作樹

Question

我想使用git將網站部署到測試服務器。 我的網站是一個用gulp構建的wordpress主題，存儲庫看起來像

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

我按照這里和這里解釋的步驟，在服務器上設置了一個裸存儲庫，配置git工作樹的位置，並寫一個post-receive掛鈎來檢查repo到那個位置。

問題是我只想將build/文件夾移動或復制到它在服務器上的位置。 我唯一的想法是寫一個post-receive hook將repo拉到一個工作樹位置（因為我覺得我讀過那個裸的repos通常都沒有工作樹），然后是cp的build文件夾進入wp-content/themes/

它似乎不必要地復雜，所以我想知道是否有更有效/更常見的方式來解決它。 謝謝！

Answer 1

你如此廣泛地使用git進行部署的approch似乎有點奇怪，主要是因為git是主要的源代碼管理系統，而不是部署工具。 確實，你可以使用git hook做許多奇怪的事情，但由於某種原因，我覺得那些回歸困擾你的傾向。

通常我會建議你使用一些持續集成工具來完成工作。 我可以使用的一個可能的工作流程是

1. 將您的主題文件存儲在GitHub的公共存儲庫中。 它是免費的，你的主題源代碼可能沒有什么大秘密，作為額外的獎勵，你甚至可以開源你的主題。
2. 使用Travis CI為您的存儲庫設置CI作業。 您基本上可以在雲中獲得免費的構建計算機實例，並且您可以在構建之前或之后執行各種操作。 你可以，例如。 在那里運行gulp build （或任何你的任務名稱），所以你根本不必將build目錄存儲在git repo中。
3. 在Travis after_success掛鈎中，您可以將構建目錄復制到目標服務器，例如使用scp 。 這是一個用FTP做同樣事情的例子 。 Travis支持敏感數據的加密 ，因此您不必擔心（至少那么多）在git倉庫中存儲用戶名和密碼。

每當您向git repo提交內容時，想要部署構建時，該流程非常有用。 順便說一句，當你第一次使用它時，它真的感覺像是魔術：“我剛剛做了這個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 。

您甚至可以參與部署任務的參數化，這樣您就可以執行以下操作： gulp deploy --test和gulp deploy --production

你去，這是你在devops的第一課。 如果軟件項目中的這種任務自動化聽起來很有趣，那么整個世界都需要學習。

Answer 2

這是簡單的git read-tree工作。 保留一個清單aka索引，用於部署目錄中的內容，並使用預接收來處理更新，如下所示：

#!/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

請注意 ，如果在部署樹中更改了以這種方式部署的某個文件，則此處的git read-tree和push將失敗，因為git不會覆蓋您沒有告訴它的內容。

Answer 3

我會把你的項目分成兩個回購。

1. 資源。 包括來源等等。 排除/ build /目錄。 僅用於源代碼管理。 這永遠不會進入網站（將代碼存儲在網站上可能不安全，即使是以git repo的形式）。

2. 部署。 只有/ build /目錄。 您可以在目錄中啟動新的git repo。 這在服務器上有一個遠程倉庫; 您可以像以前一樣使用post-receive hook進行部署。

Answer 4

我一直使用git進行部署。 它完全沒什么奇怪的，我不知道@cido對它的反對意見。 能夠及時回到“部署”分支上的任何一點，並能夠准確地看到當時服務器上的實時內容，這是非常有價值的。

不要混淆您用於存儲的git repo與您用於部署的git repo。 你應該有一個完全干凈的git樹簽出到你的生產區域（無論是什么），正如我所建議你可能想要一個單獨的分支叫做'deploy'或'production'或'staging'或者其他什么。

然后，您的post-receive掛鈎只需要運行一個進入生產區域的腳本，然后拉動您的deploy分支進行更新。

如果你需要這個對於放置在git之外的文件（例如在運行時生成的臨時文件）的git clean -dfx ，那么你可能想在拉動之前調用git clean -dfx 。 如果您希望定期從頭開始重建此服務器（例如在雲部署中），您可能還想做其他事情，但聽起來像手動進行初始設置應該可以用於您的用例。

cp荷蘭國際集團構建目錄到位聽起來不錯，只是我會使用rsync，因為它會通常會更快，如果變化是唯一的增量。