DevOps實踐－從0到1搭建敏捷團隊的持續集成環境

 

什麼是持續集成，持續部署，持續交付

1. 持續集成，是指將代碼合併到同一分支，經過編譯，測試，打包以後，將程序保存到版本庫中的過程。
2. 持續部署，是指將目標代碼自動地，定時地發佈到目標環境上。
3. 持續交付，是指自動地，定時地將最終產品交付給用戶使用。

     簡單的說，持續集成就像是軟件行業的「工業4.0」版本，經過一系列自動化的工具，將開發，測試，部署，發佈的流程定時化，自動化，這樣能夠有效地，及時地發現開發過程當中的問題，及早交付產品，快速地試錯，獲得快速的反饋，在激烈的產品競爭中獲取時間上的優點。

Git 分支模型

一圖勝千言，下面咱們一幅圖來介紹一下Git的分支模型，以及在持續集成中的做用。這裏我簡單說一下Git的分支開發模型，若是想要更詳細瞭解裏面的操做，能夠參考一下這篇文章：http://blog.jobbole.com/81196/

這裏咱們先簡單介紹一下這幾個分支：

develop:開發分支，通常開發都在上面進行

feature: 特性分支，主要是開發一些新特性的時候會建立，等到開發完了以後，合併到develop分支上，而後就會刪除。

release: 等到develop上面的特性開發得差很少了，就會建立一個release分支，這個分支上面只是用來修改bug,等到穩定以後，就切換到master上面。

master: master分支上面的Head永遠指向的是穩定的，可隨時發佈的狀態。

hotfixes:若是線上出現了任何問題，那麼就從master分支上檢出一個hotfixes分支，修復bug以後，把代碼合併到master和develop分支上。

爲何這裏要有這樣的一個分支模型出來呢？我理解是軟件開發團隊化，規劃化所致使的必然結果，這裏就急須要有一種精益求精的開發模型來適應這種變化，有點像豐田汽車的「精益生產」，這裏咱們把他暫時稱爲「精益開發」。

可是，對於一些敏捷團隊來講，自己規模就達不到這種量級，因此，更多的時候，咱們可能只用到了其中的 develop和master分支。在咱們接下來的持續集成中，咱們將經過利用jenkins做爲持續集成工具，利用develop分支，搭建一個前端項目的可持續集成，持續部署，持續交互的基本模型。

持續集成

搭建Jenkins 和 Github環境，具體的搭建環節能夠參考如下的連接。

http://www.jianshu.com/p/22b7860b4e81

網上的教程大可能是教如何搭建一個持續集成的環境，實現代碼的編譯，測試，打包，可是對於一個前端開發項目來講，在開發中，咱們更須要的是擁有「持續部署」，實現能夠看到實時反饋效果的功能，接下來咱們將結合tomcat,利用一些操做系統上的命令，來實現一個「單機版」的持續部署前端環境。

持續部署

 

首先，咱們假設你本機已經安裝好了Jenkins,也根據上述的步驟建立了一個Github的前端項目。那咱們如今碰到的一個問題是，如何將編譯好的項目部署到服務器上面。目前瞭解到的方法是jenkins集成了一些插件，能夠直接將編譯後的項目直接部署到服務器上面，例如Tomcat。 這方面已經作的很成熟了。

因爲如今不少項目是先後端分離的，先後端交互也是經過接口的形式交互，部署也是單獨部署。我在實踐中發現，對於那些對服務器有自主權的敏捷團隊，能夠將jenkins的編譯目錄和服務器對應的目錄進行連接，這樣集成後的代碼就能夠直接映射到服務器對應的目錄下，這樣內部的開發團隊就能夠經過服務器直接訪問到集成後的項目了。

這裏我只是簡單說一下整個流程，整個流程實現起來須要另外寫一片文章詳細敘說，裏面涉及到服務器設置，jenkins配置和一堆環境的配置。關於如何配置可持續部署環境，能夠看一下這篇文章：

http://www.javashuo.com/article/p-nxvueyue-hx.html