我们计划使用Hudson自动化构建系统。我们是Hudson的新手，或者最好这样说我们是构建自动化流程的新手。我们的应用程序在Java平台上，数据库在MS SQL上。这个（自动化）里程碑分为不同的目标。我们的第一步是自动化数据库更改（DDL / DML），在更新数据库期间，如果出现任何问题，它应该能够回滚更改并向组发送电子邮件以通知失败（有原因） 。否则，如果成功，则允许继续进行下一步，即使用LiveRebel进行构建和部署。
我认为如果构建失败，我们应该在任何实例上都有一个构建失败的中心机制，它应该能够回滚它本来会做的更改。例如，如果数据库更改失败，因为我说它应该通知并且不要继续进行。而且，如果数据库成功并且构建制作过程失败（例如由于单元测试），它应该能够回滚数据库更改。如果通知可能有故障详细信息（例如负责此事的人员的异常详细信息），那么对诊断和查询进行适当的检查会非常有帮助。我该如何（应该）这样做？
我们也有兴趣与Hudson一起使用LiquidBase。
我想问你的意见和建议我应该如何计划，以及应该有什么好办法实现这一目标。
答案 0 :(得分：1)
首先，您不应该混淆构建和部署。数据库更新将是部署过程的一部分，而不是构建过程的一部分。即使使用持续集成，也应将其分开。这意味着您在构建项目并运行所有JUnit测试后进行数据库更改。如果它在此之前失败，则不应执行更改，因此不需要回滚。
至于你的实际问题：我不知道任何你想做的插件。在Hudson / Jenkins中，您始终可以执行批处理/ shell脚本。编写执行更改的脚本。如果脚本以错误返回码退出，则构建应该失败。
对于发送构建失败的通知，有各种插件，包括电子邮件。