Jean-DominiqueNguele 译者
叙缘 策划
Tina 不久前我经历了一次数据迁移项目。前几天,我跟一位架构师探讨了一下当时的各个步骤,和我所选择并进一步开发的解决方案。我觉得我应该告诉他一些信息,避免他日后迁移数据时踩坑。在我们的交流中,我提到了数据迁移的各种难题和我们遇到的问题。现在我意识到,这些东西对许多从事数据迁移项目的人们来说都很有用。我听说这些是很常见的问题,多是那些开始数字化转型的公司容易遇到的。数据迁移项目通常是一套解决方案,让你提取、转换旧数据,然后将其存储到新的系统中。之前没想到的是,我从事软件工作以来只参与过一个数据迁移项目。感觉好像回到了我在学习SQL时挣扎的日子。那时的经历很有意思,你在Oracle和MariaDB上都使用PL/SQL,并为此头痛不已。你只能自行猜测哪个是旧系统,哪个是光芒万丈的新系统。但今天不讲这个,今天讲我认为导致延迟交付的最大陷阱。观点是我自己的,但事情却是大家都会遇到的。 用SQL脚本做主要工具
这是昨天早上我忘了向同事强调的一个问题,今天早上它又在我脑海闪现。别误会,SQL是强大的数据检索和显示工具。但是,当你有一个由多个开发人员组成的团队,并在同一个代码库上工作时,关键要确保你的更改能与其他代码很好地整合。
问题在于,要验证不同的场景时,我们不能只花几秒钟或几分钟运行典型的单元测试。我们必须执行实际的迁移,因此我不会称之为“集成测试”,因为集成测试的环境与实际环境有所不同(后文会详细介绍)。
我们必须启动docker镜像,然后给将来要用真实数据应对的每种场景加载虚拟数据。我觉得我们的Jenkins构建一次要2-3个小时才能完成。这使本地开发更加困难,因为没有人愿意花5分钟内改代码然后花2-3个小时来测试。最开始我们改为只运行我们需要的那些测试用例。那时CI慢到,我甚至在上一年专门发了一个帖子讲这个事情(