本博客站点已全量迁移至 DevDengChao 的博客 https://blog.dengchao.fun , 后续的新内容将优先在自建博客站进行发布, 欢迎大家访问.
前言
早先时间公司打算开拓新的业务线, 于是与一个异地硬件团队合作创立了独立的异地部门, 由于当时我们团队的研发任务比较多, 没空继续承接新业务的开发, 于是异地团队自己联系了外包团队进行业务系统的开发.
近期异地部门外包出去的软件开发维护服务到期了, 而且系统的主体已经开发完了, 因此公司也不打算继续让外包团队维护, 转而交给我们团队自己来维护, 于是出现了此次交接行动.
由于异地团队对于外包软件开发相关的需要注意的事项不熟悉, 因此在整个交接过程中遇到了一些问题, 在这里记录一下.
正文
交接群的建立
由于是异地部门直接联系的外包团队, 因此交接用的微信群是异地部门发起建立的, 然后将我们团队也拉入了交接群里. 但是建群后大家并没有主动的修改自己在群里的昵称/备注名, 而发起人自身因为和外包团队接触较多, 因此发起人也没有提议大家修改备注名.
这就导致我们进入交接群以后, 搞不清群里的人都是哪个团队的, 都各自负责哪个哪个岗位.
出现了我们团队成员在群里咨询问题半天没得到外包团队回复的情况. (也不排除外包团队有事情要忙, 一时半会儿没看到消息的情况.)
账户交接
在软件开发过程中, 异地部门直接将阿里云/腾讯云/微信小程序等平台的主账户的账户密码交给了外包团队…
Emmm, 怎么说呢, 确实是比较省事的做法, 但是有很多潜在的风险, 例如:
- 交接过程中, 双方团队共用一个主账户进行操作, 如果出现了异常, 审计时无法判断是谁导致的, 涉及甩锅不认账等风险.
- 交接完成后, 外包团队依然可以登录阿里云和腾讯云的主账户访问云上资源, 涉及未授权访问的风险.
因此我们在了解到这个情况后立即给我们团队和外包团队的相关人员分配了阿里云和腾讯云的子账户, 并且联系了异地部门负责人, 要求更换主账户的登录密码.
IP 白名单
在交接阿里云 ECS, RDS MySQL, Redis 等资源的过程中发现外包团队图省事, 直接开放了任意来源任意端口的访问权限, 并且 IP 白名单全部混在一个分组里.
这会导致 IP 白名单变得无法维护, 因此我们将白名单中的内容划分为内网和外网两个部分, 内网建立独立的白名单分组, 外网针对两个团队实际的公网 IP 另外设置各自独立的白名单分组.
代码交接
外包团队的成员在群里发完账户密码文件后, 直接丢了两个压缩包出来, 说是服务端和小程序的代码.
我们这边将压缩包下载下来解压后, 发现没有 .git 目录, 应该是被外包团队删除掉了. 于是我们尝试在交接群里找外包团队索要包含 .git 目录的代码, 得到的回复是 “你们这项目我自己开的就没有git, 当时项目比较小直接就是本地开发了”
但后续在查看服务端代码的过程中发现应该是有建立过 git 仓库, 并且托管在 Gitee 上的:
外包团队将 .git 目录删除后再发给我们, 也是可以理解的, 因为研发过程中可能用到了部分他们自己的资源进行测试, 为了避免潜在的资源泄露, 于是将 .git 目录连同相关配置文件一起删掉了. 但其实 Git 是支持对提交记录进行过滤, 并删除其中误提交的文件的.
由于缺少提交记录, 后续翻阅代码时难免会遇到一些看不懂的地方, 没有提交记录中可供参考的上下文, 就只能继续在交接群里提问了. (交接周期++)
好在外包团队的服务端还是比较负责的, 写了挺多注释在代码里, 给相关人员点个赞 👍.
云上架构梳理
接手别的团队的项目, 首先第一点就是要梳理存量的资源, 理清业务边界. 于是从 DNS 解析开始, 看看现有的域名都分配了哪些 DNS 记录.
顺着 DNS 解析记录, 并配合 ps -x | grep xxx 以及 netstat -anp | grep xxx 我们整理出了现有的云上业务大致的架构.
简单来讲, 就是一台 ECS 既当生产环境用, 又当调试环境用. 与外包团队简单的描述还是基本相符的.
一个 Nginx 对外开放 443 端口, 基于访问域名匹配下游业务. 属于是比较经典的做法了.
需求管理
自然也是没有的.
与异地部门负责人沟通后, 了解到只有一个 xxxx系统报需求单（交付源码）_V1.0_2022-05-24V1.0(3).xlsx 这样的报价单, 里面简单的记录了异地团队与外包团队就业务需求整理的工期和预算方面的内容. 报价单中没记录的事项全部都在漫长的集成测试阶段零零散散的分布在了微信群聊里.
由于我们团队只加入了交接群, 没有加入他们早先建立的合作群, 即便是现在加入, 也无法得知集成测试阶段都发生了什么事情, 进而催生出了什么样的需求和实现方式.
接口文档
想什么呢? 还接口文档?
我们也不知道当时异地团队的客户端工程师和外包团队的服务端工程师到底是怎么对接的…
总之情况就是现在这个样子, IoT 设备能跑, 服务端能跑, 小程序能跑, OK.
单元测试
基于 RuoYi 系统二开的项目就不要想什么单元测试不单元测试的了.
异地部门对这一块儿似乎并不重视, 报价单上也只有简单的 功能联调测试预计 0.5 天 的字样, 集成测试阶段持续时间比较长也似乎是情理之中的事情了.
搭建测试环境与流水线
由于异地部门的项目还是需要继续维护的, 而我们团队又不熟悉这份代码和相关业务, 因此我们打算先搭建一个独立的集成测试环境出来, 一方面是为了进一步熟悉项目的运行方式, 另一方面也是为了减少交接对现有业务的影响.
搭建测试环境的过程中有向外包团队咨询现有的服务端以及小程序的部署方式. 但外包团队响应的很慢, 回复也十分简单.
那就只能我们自己搭建测试环境和 CI/CD 流水线了.
尾款
由于交接过程并不十分顺畅, 于是我找异地部门负责人了解了一下情况, 似乎是之前联调测试没有太大问题, 外包团队就要求付尾款了.
Emmm. 维护期还没有结束就付了尾款, 难怪交接的时候外包团队有点心不在焉的感觉.
如果异地部门在谈合作的时候有考虑到维护交接期可能出现的问题的话, 应该在谈合作的时候就会要求留一些尾款在交接结束后再付的.
UI 设计图交接
由于交接过程中我方团队的注意力主要集中在服务端的迁移和小程序的代码梳理上, 因此对小程序 UI 的设计图没太在意, 一直到交接快结束的时候才向外包团队索要相关的设计图. 这里是我们团队的失职了.
我们在收到外包团队发来的 Figma 设计图源文件的时候, 发现设计图与线上运行的小程序 UI 截然不同, 尝试再次向外包团队索要最新版本的 UI 设计图时, 得到的回复是 “这就是最新版的设计图, 小程序后来的改动都是基于这个设计图去进行的, 所以没有更新版本的设计图.”, 于是我们希望外包团队联系一下设计师, 但是很不幸, 设计师离职了, 更新后的设计图也找不到了.
总结与思考
就此次项目交接的体验来说, 如果异地部门能在找外包团队合作时与我们取得联系, 并参与合作需求的制定的话, 项目的工程质量和可维护性应该能好许多.
外包团队交接过来的产品只能说能跑, 但是很多地方都透露着赶工和凑合, 这个也不能全怪外包团队, 毕竟一分钱一分货. 😂
作为甲方, 如果不了解工程实现, 而又没有专业的人员监督施工, 很容易引发乙方交付劣质工程的情况. 毕竟人是懒惰的, 工程质量不是肉眼可见的, 只有在后续维护的时候才会慢慢暴露问题.
作为乙方, 熟悉多种开源项目, 并根据开源项目快速开发业务, 确实能够帮助业务快速上线. (我要是方案供应商, 我也肯定只想着快点搞完搞下一个.) 但我认为乙方团队不应当忽略对云平台产品的熟悉, 不然公有云用起来就跟机房一样, 只会用基础产品, 每次承接新项目都是用老把式.
稍微多了一点解云平台的产品, 就可能发现自己捯饬半天实现出来的业务, 其实在云平台上配置一下就行了. 而且现在推崇 IaC, 调试好的配置文档也能快速复用于下一个项目的开发.
作为新的乙方, 应当尽早与原乙方核对交接涉及到的人和各类文件, 避免由于交接过程中乙方人员离职导致文件丢失的情况出现.
同时, 在接到新的业务需求后, 一定要先在测试环境上要求甲方配合测试, 验收通过后再进行发布, 避免由于不熟悉业务就直接操作生产环境导致各类问题, 害得大家都睡不好觉的情况出现.
相关内容
推广
欢迎大家尝试使用 Code: Certs | https://code-certs.dengchao.fun 来申请免费的 HTTPS 证书, Code: Certs 还支持自动部署到部分公有云的产品上, 降低 HTTPS 证书运维工作量.
大家遇到什么使用问题或者有任何建议都可以私信我, 或者提交到 https://github.com/code-certs/code-certs/issues 也行.
扫一扫
8129
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
