您在這裡

用Features來建立Drupal多人協同開發流程-流程圖解篇

前言

由於上一篇,已經有說明了多人協作的概念,但是似乎離清楚,還有一點距離,因此這一篇文章,想說用一些圖表,來更清楚的表達實際流程,希望能夠讓有興趣的團隊,能夠更清楚並且實行在自己的團隊內,增進開發Drupal網站的效率與時間。

流程

以下的流程,需要具備的基本技能、知識與模組如下:

  1. Git的語法語概念
  2. Drush的語法
  3. Drupal網站需要使用Features

若上述的三點,您是熟悉的,那麼可以準備來看看以下的流程圖,相信一定沒有問題囉。若上述三點有任何一項不太熟悉也沒有關係,建議可以於我們網站內尋找相關文章,或至下面留言,我們都是非常樂意分享的 :)

Step1:建立相同的開發環境/同步本機環境與線上環境一致

針對Step1,就流程來說可以分成以下5個步驟。通過這個步驟,每一個工程師可以於本機,快速把同樣的網站環境建立好。

  1. 於建立一個Drupal的git專案
  2. 建立一個Online的Develop Web Server
  3. 工程師通過Git下載所有的程式檔案
  4. 工程師通過drush sql-sync同步線上Dev Server資料庫,若不熟悉可以參考 Drush的文件
$ drush sql-sync @source @target
  1. 工程師通過drush rsync 同步線上Dev Server 的Files,若不熟悉可以參考 Drush的文件
$ drush rsync @dev @stage

當然,在這個步驟裡,主要目的是為了讓工程師可以最短的時間內,將開發環境建立好進行開發,若開發的過程當中遇到了問題,可以再搭配使用"drush sql-drop",先將資料庫刪除之後,再下一次“drush sql-sync & rsync”的語法,即可再次將本機的環境與線上環境進行同步。

Step2:於Local端進行開發

這個Step其實就不太需用多說囉,簡單來說就是每個工程師都在自己的電腦上面進行開發囉。當然,這個時候,如果每個團隊裡面有很多工程師,大家開發的項目自然是不一樣的。舉例來說,可以一個工程師寫A功能,另外一個工程師寫B功能 :)

Step3:打包

原則:全部的設定,都需要打包成為Code。

好處:No More Live Setting and Testing

相信很多Drupal工程師,對於Content Type、Views、Ctool...一堆大的模組設定都是滾瓜爛熟了,但是這個步驟的目的,即是希望將所有於本機上面開發的結果與設定,全部打包起來變成Code。變成Code之後,可以方便進行版本的追蹤驗證(例如A工程師可以把B工程師的分支於自己的電腦上面驗證開發的結果),最重要的是,可以一鍵更新於測試環境與正式環境。

工具:

  • Features : https://www.drupal.org/project/features
  • Features Extra : https://www.drupal.org/project/features_extra
  • Strongarm:https://www.drupal.org/project/strongarm
  • Commerce Features:https://www.drupal.org/project/commerce_features

方法:

  1. 用Features模組可以打包所有Entity/Ctools API等相關設定,另外使用Strongarm打包所有Variable,這兩個模組的搭配使用幾乎可以把九成以上的設定變成Features做出來的客製化模組,也就是變成“以Code為表示”的設定。
  2. 客製化模組:利用update function安裝啟用模組、或處理「所有Features無法做到的事情」
  3. 目標:將所有的設定變成「Code」,讓系統可以通過執行「資料庫更新」與「Code更新」,將新功能更新到系統。

說到這裡,也許會有人有疑問?難道連安裝新模組,都不能直接下drush指令或上網站上按下安裝嗎? 這裡的答案都是 “NO”。原因是,Code才能做好版本上的控制,也才能做到真正不同環境下的驗證。

謎之聲:

靠,好麻煩。

相信我,小編與小編的團隊們一開始也是很痛苦,但是現在習慣之後,一切都是這麼的自然與方便。 這個也是未來 要做到 持續整合( Continuous Integration)的基礎。

下圖為打包Views的截圖:

下圖為對應Views頁面的結果呈現

下面為使用模組啟用模組的範例

/**
* 安裝 安裝facebook comment 模組
***/
function hs_base_update_7001()
{
  module_enable(array('facebook_comments','blog_fb_comment'),TRUE);
}

Step4:驗證程式的正確性

如果工程師在Step3,已經順利的將開發出來的結果打包成為Code之後,要如何來驗證是否有將開發的所有功能變成Code呢?總不能直接就交給專案主任工程師去碰碰運氣吧。因此,請參照以下流程圖,應該就能夠明白。

由上圖可以看到,Step4將會需要工程師將本機的電腦再次還原到與線上端的初始設定一樣,這裡的做法當然就是利用 drush sql-drop 還有 drush sql-sync 囉。完成以後,由於於Step3已經將所有的設定都變成了Code了,這個時候只需要下以下幾個Drush指令,就可以直接將所有您於Step2開發的設定,一次都叫回來了。

Features由Code還原成設定指令

$ drush fra -y

更新資料庫指令

$ drush updatedb -y

若上述步驟做完之後,您發現全部的設定與您Step2所開發的所有設定與功能都一致時,恭喜您就完成了。

Step5:上傳程式Branch,並發佈Merge Request

這個步驟主要是工程師可以將開發出來的結果,發佈Merge Request,整合到Master主線,讓專案主任工程師,可以進行後續處理。

Step6:專案負責人驗證Branch,無誤後Merge,並且於伺服器進行更新作業

專案的主任工程師,在接到了工程師的Merge Request之後,同樣的先重複Step1的工作,然後將Step5工程師打包的結果,拉到本地端,一樣進行驗證。

在這個步驟,可以確認工程師開發的結果是否正確,設定是否正確。算是要更新到主線前的重要驗證。當然,如果這個時候檢查全部設定都沒有問題的時候,就可以將這一段程式,直接利用Git更新到develop機器或正式機器,再下更新語法即完成了更新作業。

若檢驗不合格,也可以請工程師重新做,而不會影響本來的乾淨環境。

Step7:同步本機環境與線上環境,並且重複此流程

終於到了最後一步了,大家是否也像小編一樣,鬆了一口氣呢 :) 最後一步最容易,即是重複 Step1~Step6囉! 笑~

最後用一張圖來代表整體的流程,希望能夠表達清楚。從圖裡可以看到多位工程師一起開發網站的流程囉

結論

多人協作其實一開始對於沒有習慣使用Git與Features的團隊來說,是很麻煩的。我們團隊自己當初在更改為這樣的形式時,陣痛期大約兩到三個月,但是過了之後,真的是如魚得水啊。不僅未來不再擔心開發上面造成的盲點,更可以集合大家的力量開發同一個專案,並且無痛開發與更新Drupal的設定。當然,網站上線後,後續的開發,更會顯示出這套流程很棒的地方。最後,還是要說,流程不一定是最好的,一定有可以改進的地方,若諸位讀者或專家們,有更好的建議,也歡迎一起討論囉~