我们不时邀请行业思想领袖在 IBM Systems IT Infrastructure
博客上分享他们对当前技术趋势的意见和见解。这些博客中的观点是他们自己的观点,并不一定反映 IBM 的观点。

现代软件开发团队采用了基于 DevOps 和敏捷开发技术的持续交付方法。这种方法导致的小而频繁的代码更改可以在减少更改的前置时间、降低故障率以及减少遇到错误时的平均恢复时间方面带来显着的好处。难怪 DevOps 和持续交付很受欢迎。今天的开发组织比以往任何时候都更频繁地将更改迁移到生产环境中。

到目前为止,这一切听起来都是件好事,对吧?它可以。但是,当您将数据库更改添加到组合中时,事情变得更具挑战性。2017 年数据库 DevOps 状态报告揭示了数据库开发在持续交付方面落后于应用程序开发。

对于许多 DevOps 商店来说,“Dev”往往会掩盖“Ops”部分(其中 Ops 包括数据库操作/DBA)。应用程序交付过程的控制是由开发驱动的,有时没有 DBA 组的传统控制/监督。如果没有 DBA 的专业知识,交付和集成过程可能会分崩离析,因为不能将数据库更改完全视为应用程序更改。

应用程序交付通常涉及将代码和可执行文件从一个环境复制到另一个环境。相比之下,数据库是每个环境中的完整配置,并且更改会被迁移。每个环境可能不同(尽管如此轻微)。由于优化更改、紧急更改等原因,差异可能会“漂移”。此外,考虑 Db2 包:在生产中绑定时确定的访问路径。访问路径不会(也不能)从开发环境中复制。如果没有经验丰富的 DBA 来协助、指导甚至管理流程,就会出现问题。

有时,开发人员可以自由地在测试或开发环境中进行数据库更改。这可以包括简单的事情,例如添加表、列或索引;或者它可能更复杂,需要删除并重新创建一个对象。每个 DBA 都知道删除一个数据库对象会产生级联效应,即删除和撤销其他对象和权限。但大多数开发人员并没有意识到这种变化的广泛影响。

在测试环境中,删除和重新创建结构的大更改可能是可以容忍的,因为最终用户不会受到影响,只有其他开发人员会受到影响。但是在生产环境中尝试做同样的事情可能会导致严重的中断,如果执行不当甚至可能导致数据丢失。

当应用程序更改依赖于对数据库结构的更改时,这些更改应该与驱动它们的应用程序更改紧密耦合。如果程序代码需要一个新列才能正常工作,那么您不希望在没有新列的情况下将新代码移至生产环境……反之亦然。这不仅应包括进行更改,还应包括在必要时取消更改。

需要更多地关注在技术层面和人员层面耦合软件/数据库的变化。开发团队需要 DBA 级别的专业知识来帮助指导和适当地实施变更。还需要结合和协调应用程序代码和数据库更改的自动化软件解决方案。

Tags: none

我有个想法