用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

5. 工程師通過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的設定。當然，網站上線後，後續的開發，更會顯示出這套流程很棒的地方。最後，還是要說，流程不一定是最好的，一定有可以改進的地方，若諸位讀者或專家們，有更好的建議，也歡迎一起討論囉～