將項目從 GitHub 部署到服務器
來自： http://www.oschina.net/translate/deploying-from-github-to-a-server?print
將項目從 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
小貼士：這些位置與Ubuntu的安裝路徑相關，所以一定記得要改變路徑，以滿足您的設置。該命令將檢查當前的存儲庫到定義的工作目錄，但沒有任何版本控制數據。
將文件添加可執行的權限：
chmod +x post-receive在你的本地端，像平時一樣克隆這個庫，使用你選擇的工具，并添加一個新的遠程的實時服務器（記得更改服務器的詳細信息到你的Web服務器和用戶的詳細信息）：
git remote add prod ssh://user@domain.com/var/repo/GitHub-Auto-Deploy.git要部署到我們生產環境下的服務器來替代倉庫，輸入以下命令：</span>
git push prod master你可以ls一下服務器的 var/www/html 目錄，可以看到index.html文件已經被自動拷貝進你的web文件夾內啦。
如果你使用的是自己的Git倉庫，你可以把它配置在同一臺服務器上的應用，并實現自動化部署。如果你使用的是GitHub上或其他外部Git的服務，那么這個鉤子還沒有完全自動化，但它已經降到了一步。這可以進一步簡化。
GitHub的post-receive 鉤子中有一個可以使用reync或scp的選項。這是另外的一種選擇——特別是當你的應用需要構建時（GitHub限制了可能的命令）——是使用post-receive 鉤子來觸發，然后使用-f選項可以檢查出從GitHub的代碼庫的應用程序服務器上的腳本和運行其他一些必要的命令。這個時候，自動化部署開始變得復雜起來，我們不得不使用下一套工具來更好的完成。
從 GitHub 直接自動部署
GitHub 有它自己的文檔來自動化部署到集成平臺，這里包括一些托管提供商。
老實說，大部分文檔都有些錯誤，不準確或者沒有起到作用， 在一些主流的主機提供商那兒，我做了一些搜索鏈接到官方文檔，對于其他一些提供商，我建議你使用 post-receiveor 持續集成的方法：
持續集成(CI)服務
有許多無數的能夠查看 GitHub 項目回購變更協議的應用服務，不僅能夠為你部署，而且能夠執行其他功能，諸如為你運行測試和構建過程。
一旦你移動到一個新的和更復雜的實例時，我們可以使用 CI
自動化構建項目過程。首先，拉伸一個存儲庫的 Master 分支，然后觸發一個運行構建的 bash 腳本，并且部署流程以及對微博更新。CI 與 web 服務能夠在同一臺服務器上或者在不同的服務器上運行，這一切都取決于你的偏好。
讓我們迅速一覽其最受歡迎的部分吧。
Jenkins
你需要搭建你自己的 Jenkins 服務器，這意味著你可以完全地控制它，但必須要對它進行維護。幸運的是，它提供了多平臺支持，如果你只是想要先簡單嘗試一下的話，這些支持也包括了 Docker。
Jenkins 使用插件實現了自己的大部分功能，并且由于其年代久遠、開源的性質以及普及度很廣，它擁有很多的插件。例如，有一些 Git、GitHub 和 推ter 的相關插件。
Jenkins 需要大量的配置，而且有時，若想要將你需要的指令組合到一起來構造你所需的工作流程，可能需要大量的研究。
Travis
此外，在 GitHub 文檔中，使用 GitHub 的 Travis 集成指令已經過時。現在，它更簡單：閱讀找出更多的 Travis 文檔。
Travis 不需要任何主機與服務器設置，因此你無需投入太多的精力，就可以保持和試用CI，這是一個很好的起點。不過，擴展超出（綜合）默認的集成將涉及到一些額外的配置工作。比如，微博請求對 webhooks 的訪問。
在回購中，你會注意到 Travis-- 特別是在配置自己的文件中，它有一個習慣，就是更新太慢。當你本身沒有對 Travis 服務器進行訪問時，那么這些問題就難以解決。
其他商業服務
持續集成已經日益流行了，所以已經有了非常多的新的服務和應用程序 – 很多是通過你可能已經在使用的工具的創作者釋出的，并且將很和諧的融入到現有的工具鏈和工作流程當中。這里有些例子：
總結
希望這篇簡要的介紹已經為你闡明了關于這種部署方式是如何工作的一些事情。當然，我們還有很長的路來實現通過 FTP 將你的文件傳到你的服務器！
如果你對上述流程有任何疑問，請在評論區中讓我知曉。
Tags: auto deployment, continous deployment, git, git hooks, github, server side hooks
</div>本文地址：http://www.oschina.net/translate/deploying-from-github-to-a-server
原文地址：http://www.sitepoint.com/deploying-from-github-to-a-server/
</div>我們的翻譯工作遵照 CC 協議，如果我們的工作有侵犯到您的權益，請及時聯系我們