我认为这没有简单的食谱答案,因为这在很大程度上取决于您的环境。无论您想出什么,我都强烈推荐一种基于脚本的方法,部署脚本本身就在源代码控制中。这些脚本还将允许与构建解决方案更好地集成(见下文)。
在生产环境中运行的最简单的此类脚本就是从源代码控制获取最新(或获取特定版本)的命令。
下一个挑战是数据库部署。对于中小型项目,我最喜欢的解决方案是在每个数据库中维护一个模式版本表,并将所有 DDL 和数据更新脚本放在源代码控制中(包括它们在压缩档案中使用的数据源)。脚本是连续编号的(从 000001 ...、000002 ...等开始),我运行的部署脚本只是首先备份现有数据库,然后从架构版本表中获取上次运行的数据库脚本,然后运行在源代码控制中以正确顺序找到的任何新数据库脚本,相应地更新架构版本表。
这种方法使我可以非常快速地从头开始重建数据库。
这两种方法结合在一起可以将您的代码库快速部署到几个不同的登台机器、您的 QA 环境、测试版等。
对于稍微复杂一点的场景,您应该运行一个持续集成构建服务器,例如 Kieveli 等。人。建议,它基本上定期“重建”您的整个部署,因此包含脚本来完全执行您将在上面“手动”运行的内容。
通过为每个数据库脚本创建一个回滚脚本,也可以使数据库部署更加复杂。然后,您应该编写一个小控制器应用程序来处理这些问题。这类东西有几种 OSS 解决方案,其中一种可能适合您的需求。
但是,请确保您永远不会将数据库自动部署到生产环境;-)