持續集成和數據庫管理

與其他幾個人一起工作時，通常會有幾個人在不同區域工作，例如數據庫。持續集成和數據庫管理

我的挑戰是如何讓幾個人在持續集成環境中編輯數據庫模型。

開發人員建議編寫一個「版本控制腳本」，其中將每個編輯輸入到.sql腳本中，並使用數據庫能夠檢測到的版本號。在該文件中添加一個新的模型會在文件中加上一個版本的標籤，並且一旦腳本被提交併且一個構建已經運行，數據庫就會被更新。

我也聽說過發佈者/訂閱者...並閱讀了一下。

如何在日常工作中管理這種情況，並且您可以給我哪些建議以使數據庫更改儘可能無縫地運行？

**編輯**

已經提到了遷移框架和遷移腳本。如果你有一些實踐經驗並且會提出一個框架，那也是值得讚賞的。

來源

2009-10-25 CodeMonkey

中的出色Get Your Database Under Version Control後報價傑夫阿特伍德：

...

我在想這又因爲我的朋友和co-author K. 斯科特·艾倫剛剛寫下輝煌的五部分的數據庫版本控制練習：

Three rules for database work

The Baseline

Change Scripts

Views, Stored Procedures and the Like

Branching and Merging

...

真的，全系列值得一讀，即使你們中許多人似乎是特別感興趣的第三部分。順便說一句，看看第三部分提到的Bulletproof Sql Change Scripts Using INFORMATION_SCHEMA Views文章。您可能已經意識到這一點，但它解釋了爲什麼編寫idempotent更改腳本很重要。

關於工具，你可能想看看UpToDater（代碼中心），LiquiBase（基於XML）或... dbdeploy的基礎上，ThoughtWorks的軟件開發的現實世界的經驗有點寶石。這不是說第一個不好，但這是我的首選（可用於Java，PHP或.NET）。

來源

2009-10-27 00:01:16

如果我不僅限於1人，我會贊成18次：D – whaley 2009-10-28 17:41:33

讓你的奶奶投票然後:)更嚴肅地說，很高興你覺得它有幫助。 – 2009-10-28 17:52:55

感謝您的鏈接。希望3條規則中的項目＃1有更多細節。它是我們現在正在努力的東西。說起來容易做起來難。 – CodingWithSpike 2009-10-28 18:20:43

檢出遷移框架。 AFAIK，這個想法來自於rails，但是現在人們已經爲其他所有東西構建了框架。

來源

2009-10-25 21:41:17

我傾向於使用'遷移'腳本，這是從簡單的版本化腳本開始的下一個階段。通過遷移，您可以指定對數據庫所做的更改（添加，刪除等）以及如何撤消遷移正在執行的更改。然後用一個不會與其他開發人員衝突的某種形式的版本標記。一個特別好的版本號是當前時間（以YYYYMMDDHHMMSS格式或者距離紀元秒）。這是一個不錯的選擇，因爲您不太可能發生版本衝突，並且由於此類時間戳的嚴格增長性質，仍然很容易發現是否存在新版本。

注意：這受到Rails中的遷移系統的很大影響。對於更多細節和想法，我強烈建議查看該系統。

的Rails遷移：

class CreateGroups < ActiveRecord::Migration 
    def self.up 
    create_table :groups do |t| 
     t.string :name 
     t.references :owner 

     t.timestamps 
    end 
    end 

    def self.down 
    drop_table :groups 
    end 
end

主義遷移：

class CreateGroups extends Doctrine_Migration 
{ 
    public function up() 
    { 
     // Create new author table 
     $columns = array('id' => array('type'   => 'integer', 
             'length'  => 4, 
             'autoincrement' => true), 
         'name' => array('type'   => 'string', 
             'length'  => 255), 
         'owner_id' => array('type' => 'integer', 
              'length' => 4)); 

    $this->createTable('groups', $columns, array('primary' => array('id'))); 
    } 

    public function down() 
    { 
    $this->dropTable('groups'); 
    } 
}

（對不起，缺乏學說時間戳的......在軌道中的時間戳呼叫created_at和的updated_at字段的表補充說，是自動爲你管理的，我不確定在教條中有類似的行爲，所以我把它們排除在外）。

來源

2009-10-25 21:41:43 workmad3

我很想看到一個遷移腳本示例，如果你有一個？ – CodeMonkey 2009-10-25 22:35:35

我第二個示例請求。 – Martin 2009-10-25 22:54:45

今天晚些時候我將添加一個rails遷移示例，以及一個大致相同的原則遷移。 – workmad3 2009-10-26 12:11:07

這取決於。

如果這是您正在討論的發佈產品，則需要仔細跟蹤架構編輯，以便您可以規劃升級過程。現在開始思考這個問題會很好，所以「版本控制腳本」在某種程度上是有意義的。但向後/向前兼容通常只是用戶可見的需求，而不是「編譯之間」的需求。在發行版之間，維護一個升級腳本來修改數據庫表以將其提升到新的模式是有意義的。

如果這是一個新/未發佈的產品，如果有人更改了架構，您會關心什麼？爲什麼你甚至想要在持續集成構建之間保持數據庫？無論如何，您應該能夠通過自動化測試重新生成任何測試數據。但是，更改架構的任何人都應該更新測試。

對於已發佈的產品，您可能希望擁有一組可以處理「1.0版」數據庫的測試，以確保它可以成功升級到「1.1版」（例如）。

來源

2009-10-25 21:45:35 mpontillo

我們在Subversion中編寫所有腳本，並將其與任何其他代碼一樣檢入到項目中。所有的數據庫部署都是從源代碼管理系統提取的腳本完成的。如果兩個人碰巧正在使用同一個腳本（這相當罕見），Subversion會讓你合併這兩個腳本。

來源

2009-10-26 12:59:15 HLGEM

問題中沒有描述技術堆棧（包括使用的數據庫），這與哪種解決方案最適合非常相關。

非常流行的以Java爲中心的遷移解決方案是Flyway。 DBUp是非常相似，但專注於.NET堆棧。

在Redgate，我們提供ReadyRoll，它緊密集成到Visual Studio中，專門針對SQL Server。

來源

2016-09-29 09:34:59

持續集成和數據庫管理

回答

相關問題