Michael Huttermann是一位经验丰富的软件工程师,在DevOps和数据库开发方面有着独到的见解,他通过自己的实践描述了DevOps在数据库管理方面的应用,值得借鉴。
DevOps一词描述了开发团队和运维团队之间改进的协作。它描述了简化软件交付流程的实践,强调从产品到开发的流动反馈中学习,并缩短循环时间(也就是从启动到交付的时间)。 Michael指出,DevOps不仅能让你交付软件过程更加快捷,还能帮助生产更高质量的软件,这些软件能够更好的满足个体需求、也更符合基本情况。
DevOps寻求开发团队和运维团队之间共同的目标、概念和工具,致力于通过共同目标、概念、工具来提高开发团队和运维团队间的协作。 DevOps降低了组织障碍。通过“一个团队方法”,敏捷实践可以扩展到运维部门。来自开发团队和运维团队的专家现在都是“开发者”了,这意味着他们可以一起工作来“开发”解决方案。
DevOps包含许多活动和方面,包括:
- 文化。强调人超过过程和工具。软件是人开发的,也是为了人开发的。
- 自动化。自动化是DevOps迅速获得反馈的关键。
- 测量。DevOps为测量制订了特殊的方法。质量和共享(至少是一致的)激励是必要的。
- 共享。共享构建了一个合作的平台,通过这个平台可以交换想法、知识和经验。
开发团队和运维团队间常常存在一些纷争,引起这些纷争的主要原因如下:
- 不同的目标:开发团队追求短时间内做出更多改变;运维团队希望产品少一些改变,多一些稳定性。
- 不同的流程和概念:开发团队采用重实效的方法;运维团队更注重方法的可重用性。
- 不同的工具:开发团队使用开发工具;运维团队采用类似产品的方法。
Michael指出,在传统的设置中,开发一词描述的主要是开发团队的程序员。测试人员也是团队中的一部分,但他们通常有专门的项目角色,而且他们常常是在程序员完成编程工作后才开始自己的工作的。运维一词指包括数据库管理员、系统管理员、网络管理员和其它各种管理员在内的团队。这些专家将软件投放到生成并且管理产品的基础设施(例如,设置和维护服务器和系统)。运维团队实际上会跟随到交付流程直到“最后一步”。在障碍重重的环境下,两个开发团队形成了两个孤岛,他们有自己的优化的目标和过程、工具。
软件开发人员可以应用包括连续提交和自动测试在内的持续集成,此外,他们也应用面向目标环境的商业应用程序持续部署。但是数据库开发者往往缺乏对真实数据库版本控制和持续部署的基础。应用程序开发/部署和数据库开发/部署间的主要差异导致了这些隔阂。传统上讲,应用程序开发基于本地文件,只有在提交时才会发布本地变化。开发人员可以在本地修改、调试代码,同时不影响团队其它成员的工作。而部署工作则是通过自动复制从构建服务器到各自环境的交付结果进行的。
另一方面,数据开发常常是基于核心资源的。尽管在许多情况中,核心数据库可以通过本地开发数据库或个人模式提供孤立的、高效的工作环境。除此之外,数据库部署不是简单的复制和替换过程。例如,一个数据库表不能被简单的删除,然后再由新结构重新创建。数据库部署往往不存在两个完全相同的部署,因为源文件或者目标文件往往被旧的或者新的部署修改或者更新。
在软件工程中,数据库常常是关键路径。Michael认为,在定义和推出数据库DevOps时,区分四个区域将对我们十分有帮助。如图展示了DevOps区域矩阵方法。
- 区域1是将开发扩展到运维。在数据库内容中的一个常见用例是将脚本转换放到版本管理系统,并在开发工作和运维工作中使用相同的数据库移植工具——如Flyway。
- 域2是将运维拓展到开发。对于数据库DevOps,这意味着为产品系统中的交互提供能见度,包括行级锁、阻塞查询和资源竞争。
- 域3将开发嵌入到运维中。这种例子包括为非功能性需求设置限制和共同目标。共同目标:如80%的数据库查询操作会在2秒内将查询结果返回到屏幕上(一个共同的性能目标);系统不应当使用任何将导致此系统难以移植到另一个Linux版本上的技术(一个共同的可移植性目标);数据库在指定的硬件上可以存储两千万成员,同时仍能满足性能目标(一个共同的容量目标);或者自动测试必须存在于包括基础设施代码在内的所有部门(一个共同的可维护性目标)。
- 区域4将运维嵌入到开发中。这一区域提供了获得数据库管理员们(DBAs)未参与的开发的信息的权限,防止DBAs成为看门人,通过完成这一区域可以加强合作。
Michael认为,一个稳健的数据库变更管理解决方案是克服日常挑战的最有效的方式。通过使用诸如版本控制、持续集成、自动操作的特性,数据变更管理使DBA和开发者之间可以更好地交流、合作,这避免了潜在的问题——意外冲突、覆盖等等——当他们分开工作时这些问题都可能出现。而这个稳健的数据库变更管理解决方案也将从DevOps策略中得到更多回报。Michael认为,下面的模式可能帮助促进DevOps,特别是数据库DevOps。包括:
- 使用数据库更新脚本。通过DevOps,数据库元素可以伴随更新脚本自动发布。
- 自动发布数据库。自动发布数据库面临的一个更难的挑战是链接当前版本的数据库(也就是当前的结构元素,如表和列,和数据),换句话说,在它的当前状态——和其它构成完整版本的东西的当前版本。通过保证数据库元素在版本控制下,你可以创建标签并把你的所有配置项添加到定义好的库中。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
如何减少不必要云服务成本
由于初始成本相对较低,业务经理有时候可控制自己的云预算,但这既是好事也是坏事。 企业可以不受IT干扰,但业务经 […]
-
“以建应变”:敏捷+DevOps驱动数字化转型
数字化转型由软件驱动。如今在数字化转型中,交付软件实际上处于每一个业务的核心,这一软件趋势也正好与CA Technologies一直强调的应用经济相一致。
-
AWS实现DevOps:思维与工具集并重
开发与运营(即DevOps)模式让IT团队能够以比传统部署方法更快的速度来发布应用程序。很多企业已经依赖AWS用作云平台以提高敏捷性、降低成本支出以及减少用于生产应用程序的时间。
-
”用好云“:企业如何最大化云计算价值?
无论是个人,还是企业都已经感受了云技术所带来的便利,享受到了云计算带来的成本节约。但是,在企业普遍认可、应用云计算的时刻,我不禁要问一句”你真用好云了吗?