將專案從 GitHub 部署到伺服器

oschina發表於2016-02-01
Github伺服器

GitHub以及它所依賴的版本控制系統Git，絕對是非常出色的專案管理和協作的工具，不管專案是不是跟程式碼相關。

本文會討論有哪些選項可以讓Git和Github更好的融入專案的工作流當中，以實現平滑的自動化的過程。

我把這些選項劃分到不同的工具集當中，這些集合包括自動執行測試，以及拉取程式碼部署到伺服器上等等。

為何要這樣做？

有了這些自動化過程的執行，你和你的團隊就可以只關注單純的編碼以及程式碼的合併，而不是每次build的時候都要花費幾個小時去重複的做部署這樣的事情。

自動化的缺點

自動化部署變化的主要問題是變化會自動地被部署。你必須信任你的團隊以及他們寫的程式碼。這就是為什麼自動化部署和自動化測試的搭配成為典型，而下面提供的工具也反映了這一點。

來源於此文作者的更多內容

當然，這同樣意味著仍和小問題也一樣地被快速修復。自動化應該與溝通配合。如果推送到一個庫的主分支會引發住建，需要明確，當這種情況發生時誰去做這件事情。

一個自動化的初始設定過程可能需要一些時間。因此權衡你的團隊或者工作流程是否真正的需要它是一件重要的事情。把你們花在測試和部署新的構建上的時間加起來——如果是每次超過幾分鐘，那麼它是值得的。

Git Hooks

Git內建了一套擴充框架叫做鉤子（http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks）用來處理自動化部署，並且這些鉤子一般在被特定的Git事件(certain points)觸發後被呼叫在我們的第一埠用來處理任務。鉤子可以被分為伺服器端鉤子與客戶端鉤子。

伺服器端是用於監聽網路操作的事件 ——比如，當儲存庫接收推送後。而客戶端掛鉤的觸發是因為開發者進行了操作，如提交和合並。

這是在Git文件中hooks的完整列表（http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks）。我會註釋一對情侶在這裡讓你開始。希望這能讓你在自己當前手動部署的專案工作流程中中變得非常有用。Hooks可以在任何語言的專案部署中執行，強大而靈活。

pre-commit

此這個鉤子執行在其他所有鉤子之前，並且在更改提交之前。可以用來在提交前檢查程式碼錯誤。

我們在這裡寫一個JavaScript的小專案說明（當然，我故意留了你可以找到的bug）。

重新命名hooks/pre-commit.sample 為 hooks/pre-commit，並進行如下測試命令，以這樣的內容：

#!/bin/shjshint index.js

試著提交這個變動：

git commit -m "adding Javascript file"

你可以看到報錯資訊：

index.js: line 5, col 25, Missing semicolon.1 error

新增缺少的分號後重新提交，不在報錯。

post-receive

當推送遠端Git倉庫完成時，伺服器端的該鉤子觸發。在這個例子中，我們推出一個簡單的網站的最新版本到你的Web伺服器目錄，實際上是一個（最基本的）部署。

我有一個現有的網站包含有一個index.html頁 – 以及我們在後面的例子將使用的其他網頁。你也可以建立自己的，使用在這裡設立倉庫。

克隆倉庫，通過指定–bear標記來建立一個只包含版本控制資訊的儲存庫，而不是我們的程式碼倉庫：

git clone --bare https://github.com/sitepoint-editors/GitHub-Auto-Deploy.git GitHub-Auto-Deploy.git

現在我們新增鉤子：

cd GitHub-Auto-Deploy.git/hooksvi post-receive

新增這些到檔案中：

#!/bin/shgit --work-tree=/var/www/html --git-dir=/var/repo/GitHub-Auto-Deploy.git checkout -f

注意：這些路徑是基於Ubuntu環境下完成，所以記得要改變路徑，以滿足弄的路徑。

該命令將推出當前倉庫到定義的工作目錄，但沒有任何版本控制資料。

更改檔案屬性使之可執行：

chmod +x post-receive

從 GitHub 直接自動部署

GitHub 有它自己的文件來自動化部署到整合平臺，這裡包括一些託管提供商。

老實說，大部分文件都有些錯誤，不準確或者沒有起到作用， 在一些主流的主機提供商那兒，我做了一些搜尋連結到官方文件，對於其他一些提供商，我建議你使用 post-receiveor 持續整合的方法：

持續整合(CI)服務

有許多無數的能夠檢視 GitHub 專案回購變更協議的應用服務，不僅能夠為你部署，而且能夠執行其他功能，諸如為你執行測試和構建過程。

一旦你移動到一個新的和更復雜的例項時，我們可以使用 CI

自動化構建專案過程。首先，拉伸一個儲存庫的 Master 分支，然後觸發一個執行構建的 bash 指令碼，並且部署流程以及對微博更新。CI 與 web 服務能夠在同一臺伺服器上或者在不同的伺服器上執行，這一切都取決於你的偏好。

讓我們迅速一覽其最受歡迎的部分吧。

Jenkins

你需要搭建你自己的 Jenkins 伺服器，這意味著你可以完全地控制它，但必須要對它進行維護。幸運的是，它提供了多平臺支援，如果你只是想要先簡單嘗試一下的話，這些支援也包括了 Docker。

Jenkins 使用外掛實現了自己的大部分功能，並且由於其年代久遠、開源的性質以及普及度很廣，它擁有很多的外掛。例如，有一些 Git、GitHub 和 Twitter 的相關外掛。

Jenkins 需要大量的配置，而且有時，若想要將你需要的指令組合到一起來構造你所需的工作流程，可能需要大量的研究。

Travis

此外，在 GitHub 文件中，使用 GitHub 的 Travis 整合指令已經過時。現在，它更簡單：閱讀找出更多的 Travis 文件。

Travis 不需要任何主機與伺服器設定，因此你無需投入太多的精力，就可以保持和試用CI，這是一個很好的起點。不過，擴充套件超出（綜合）預設的整合將涉及到一些額外的配置工作。比如，微博請求對 webhooks 的訪問。

在回購中，你會注意到 Travis– 特別是在配置自己的檔案中，它有一個習慣，就是更新太慢。當你本身沒有對 Travis 伺服器進行訪問時，那麼這些問題就難以解決。

其他商業服務

持續整合已經日益流行了，所以已經有了非常多的新的服務和應用程式 – 很多是通過你可能已經在使用的工具的創作者釋出的，並且將很和諧的融入到現有的工具鏈和工作流程當中。這裡有些例子：

總結

希望這篇簡要的介紹已經為你闡明瞭關於這種部署方式是如何工作的一些事情。當然，我們還有很長的路來實現通過 FTP 將你的檔案傳到你的伺服器！

如果你對上述流程有任何疑問，請在評論區中讓我知曉。

相關文章