問題描述
持續集成中的數據庫變更管理 (Database change management in continuous integration)
What's the best way to add database changes management to a continuous integration scenario? I've read some questions and answers but they are from 2009 and there are surely some techniques and tools that were developed in the meantime.
I'm using TFS 2010, but that's not the point. I'm interested in the concept of how to manage database changes alongside continuous integration. Any ideas?
‑‑‑‑‑
參考解法
方法 1:
I'd recommend the Red Gate stack with SQL Source and Compare ‑ it definitely can go a long way to having a fully working CI environment with sql integration
方法 2:
We've successfully used Liquibase for database change management.
Using the best pratices you can define several changelogs for database and keep all the environments up to date with help of your CI server (in our case, TeamCity).
方法 3:
Apart from Red Gate tools you can also try using ApexSQL Diff and ApexSQL Version to accomplish the same thing.
You can’t go wrong with any of these tools and if you want a third option you can check out tools from Idera.
Note that all of these are commercial tools though but they all do have 14‑30 day trial.
方法 4:
We've just release our Database Enforced Change Management solution (a commercial solution), DBmaestro TeamWork, for the SQL Server.
It enforces the version control process on the real database objects (and not on scripts which are disconnected from the database)
It generates the sql script to promote changes using baseline aware analysis which understand the nature of the change such as: change should be ignored as it was originated from a different branch or critical fix or there is a conflict and you must merge the procedure code.
Disclaimer – I'm working at DBmaestro.
Having said that I would encourage you to read a comprehensive, unbiased review on Database Enforced Management Solution by veteran Database expert Ben Taylor which he posted on LinkedIn https://www.linkedin.com/pulse/article/20140907002729‑287832‑solve‑database‑change‑mangement‑with‑dbmaestro
方法 5:
We have a new solution that takes the following approach:
- Developers script individual SQL changes and commit them to source control.
- Our program (OneScript) pulls the change script files from source control, filters and sorts them, and generates a single release script file. (Works better than it sounds.)
- That release script file is then applied to a database to do a release.
Our home page here explains this process in more detail. It also has a link to an example that does these steps automatically from a Subversion hook (but this could also be from TFS). So soon after a commit, the developer receives an email saying if the release was successful or had errors. The PowerScript code is included.
The idea is that eventually you have a release script that is fully tested and that same exact script moves through all of your pre‑prod environments and is eventually used to apply the release to your prod database.
Disclaimer ‑I work for the company that makes OneScript.
(by Dante、Matt Whetton、giacomelli、Kenneth Hampton、Uri、JBrooks)