Drupal源代碼控制策略？

Question

在標準的基於php或源代碼的項目中，我們可以輕鬆地將所有代碼保留在SVN中，並且每位開發人員都可以簽出自己的副本並在相同的代碼上進行協作。

然而，當開發一個Drupal站點時，大部分工作都在「設置」中。除了主題和模塊之外，您還沒有任何「源代碼」。你如何運行同一個站點的多個實例，以便開發人員可以同時工作但共享他們的工作？

示例場景：

我們推出Drupal站點的內容類型爲「X」創建的最初版本。我們最初還在網站上按時間順序列出了所有類型爲「X」的節點。客戶端開始使用該站點，添加內容，菜單項等。

下一個版本計劃將用戶搜索能力添加到該視圖。雖然它的設置包含在數據庫中。我們可以將生產數據庫複製到我們的開發版本，以便在改變視圖的同時獲取最新數據。但是在那段時間，客戶端仍然可以更新網站，使我們的開發數據庫不同步。當我們準備將新視圖推向生產時，除了手動重複在生產安裝上設置它的步驟之外，是否有更簡單的方法來完成此操作？

Answer 1

我認爲一個好的策略是使用安裝配置文件API。使用安裝配置文件API，您可以使用Drupal管理工具執行大部分操作。大多數核心形式只是在變量表中設置變量。爲了能夠明智地版本化您的非內容數據庫內容即配置使用更新功能是明智的。

在我的網站上，我們有模塊「ec」，除了它的ec.install文件包含更新功能， ec_update_6001（）

您的主要安裝功能可以負責在您進行的任何新安裝中實際運行更新，以使您的模塊保持最新狀態。從我們的實際文件

function ec_install() { 
    $ret = array(); 
    $num = 0; 
    while (1) { 
    $version = 6000 + $num; 
    $funcname = 'ec_update_' . $version; 
    if (function_exists($funcname)) { 
    $ret[] = $funcname(); 
    $num++; 
    } else { 
    break; 
    } 
    } 
return $ret; 
} 

樣本更新功能或兩個現在跟隨

// Create editor role and set permissions for comment module 
function ec_update_6000() { 
    install_include(array('user')); 
    $editor_rid = install_add_role('editor'); 
    install_add_permissions(DRUPAL_ANONYMOUS_RID, array('access comments')); 
    install_add_permissions(DRUPAL_AUTHENTICATED_RID, array('access comments', 'post comments', 'post comments without approval')); 
    install_add_permissions($editor_rid, array('administer comments', 'administer nodes')); 
    return array(); 
} 
// Enable the pirc theme. 
function ec_update_6001() { 
    install_include(array('system')); 
    // TODO: line below is not working due to a bug in Install Profile API. See http://drupal.org/node/316789. 
    install_enable_theme('pirc'); 
    return array(); 
} 

// Add the content types for article and mtblog 
function ec_update_6002() { 
    install_include(array('node')); 
    $props = array(
    'description' => 'Historical Movable Type blog entries', 
); 
    install_create_content_type('mtblog', 'MT Blog entry', $props); 
    $props = array(
    'description' => 'Article', 
); 
install_create_content_type('article', 'Article', $props); 
return array(); 
} 

實際上，這大多與數據庫和Drupal代碼解決了版本控制問題。我們廣泛使用它。它允許我們推廣新的代碼，這些代碼可以改變數據庫配置，而無需重新導入數據庫或進行實時更改。這也意味着我們可以正確測試版本而不用擔心隱藏的數據庫更改。

最後，cck和views支持這種方法。看到這段代碼片段

// Enable CCK modules, add CCK types for Articles in prep for first stage of migration, 
// enable body for article, enable migration modules. 
function ec_update_6023() { 
    $ret = array(); 
    drupal_install_modules(array('content', 'content_copy', 'text', 'number', 'optionwidgets')); 
    install_include(array('content', 'content_copy')); 
    install_content_copy_import_from_file(drupal_get_path('module', 'ec') . '/' . 'article.type', 'article'); 
    $sql = "UPDATE {node_type} SET body_label='Body', has_body=1 
    WHERE type = 'article'"; 
    $ret[] = update_sql($sql); 
    return $ret; 
} 

Answer 2

前段時間我寫了一篇關於painless Drupal revision control with CVS and Subversion最佳實踐的文章。

不幸的是，仍然存在源代碼控制數據庫的問題，正如您已經指出的那樣。有幾個建議的方法，我在additional post中提到。

Answer 3

如果您使用svn:externals屬性，您可以節省自己對配置和使用SVN的一些痛苦，如Nick的文章中所述。這將使Drupal的本地版本自動與指定的Drupal分支保持最新，並且您可以爲模塊使用完全相同的機制。另外，因爲SVN會從文件中讀取外部定義，所以你可以把它們放在版本控制之下！

我不認爲CVS具有等同的功能。然而，編寫一個簡單的腳本很容易，它會自動安裝一個Drupal模塊，只需要一個URL（我已經完成了這個工作來保持我自己的Drupal站點是最新的）。

就版本化數據庫而言，這是一個要解決的棘手問題。我建議將一個「股票」Drupal數據庫導出到一個SQL文件並將其放在版本控制之下。每個開發人員都有自己的本地專用數據庫服務器來使用。然後，您可以提供一個腳本，將指定的數據庫還原爲包含在SQL文件中的股票版本。

作爲其他方式解決這個問題的例子，我將描述工作中的情況。我在一個Web應用程序上工作;它不使用數據庫，因此不會遇到這些問題。我們避免重複設置站點的方法是從源代碼管理重建，並提供一個程序來實現站點的自動部署。該程序也被我們的客戶用作創建網站的方式。

Answer 4

某些模塊（如CCK和Views）允許以文本形式導出和導入其設置數據。您可以將這些文本表示保存在源代碼管理系統下。

Answer 5

把Drupal的設置從數據庫轉變成代碼一直在向前跨越式發展。在這個領域真正有幫助的兩個模塊是：

Features - 允許您收集實體，如內容類型，分類，視圖，甚至是提要。我們正在非常成功地使用它，並且可以在開發人員之間共享這些更改。

Strongarm - 允許使用上述模塊存儲和導出變量。我已經對這個模塊進行了一些測試，但我們沒有使用它，很簡單，因爲我們確實不需要這些功能。

這些解決了在數據庫中保持站點設置的最大問題。但它們並不完美。 。 。我們發現不正確支持或支持的模塊。

Answer 6

不幸的是，這裏沒有一個好的/簡單的解決方案。這個問題不僅僅是Drupal架構的一個不幸的副作用，而且還包括所有框架類型的CMS，其中通過配置（即存儲在數據庫中的數據）通過源代碼定義應用程序的次數很多。管理配置數據的兩個選項都不是很好。首先是你在做什麼：定義一個單一的數據庫作爲規範（即生產數據庫），並讓開發人員在生產數據庫的快照本地工作，並通過生產站點通過手動配置將新配置信息「合併」到生產數據庫中管理界面。在定義明確的子系統（即視圖）的情況下，您可以利用開發的導入/導出功能來簡化這種配置遷移。第二種選擇 - 即我認爲你正在尋找的自動化 - 很困難，但對於具有複雜項目自動化預算的大型項目來說可能是值得的 - 或者需要 - 深入研究系統/模塊數據庫結構並開發自定義腳本將表/記錄級別的新配置數據合併到生產數據庫中，例如，作爲最新數據庫的夜晚「構建」的一部分。怕那裏沒有任何中間解決方案。

在歷史跟蹤配置數據的版本控制方面，像backup_migrate這樣的模塊允許您執行db的自動SQL轉儲。您可以通過定義備份「配置文件」來選擇轉儲哪些表，並且可以創建一個將大型內容，日誌記錄和緩存表（例如節點，cache_content，看門狗）從轉儲中移出的應用程序，以便爲版本控制留下更易於管理的塊。服務器或其他地方的一些簡單腳本可以獲取最新的轉儲並將其添加到您的存儲庫。

Answer 7

Drupal現在支持可導出配置，它允許您將大部分站點配置移動到代碼。在features模塊的幫助下，可導出配置支持配置變量，視圖，內容類型，字段，輸入格式等。

您還可以通過中央控制器配置文件或模塊來管理初始的，不可導出的配置和配置更改。使用它來啓用模塊，創建用戶等。

請參閱The Development -> Staging -> Production Workflow Problem in Drupal和Code driven development: using Features effectively in Drupal 6 and 7演示文稿。