最近,我收到一位读者的私信,他最近"内耗"得非常厉害,他可能一时兴起把我的私信当作了吐槽箱。
他们公司一直实行敏捷的管理模式,复盘发现了一个问题:发布与迭代具有强相关性,一个迭代就发布一次,导致需求交付周期过长,严重超出团队和业务部门可接受的时限。现在他在考虑到底该如何改变,是选择SAFe还是DevOps。
卡尔·波普尔曾说:"新的基本原则是,为学会避免犯错误,我们必须从我们的错误中学习。"敏捷本身并不能带来投资回报。当改进开发流程而不改进部署时,我们最终不可避免会面临这些问题。我之前陆陆续续写过一系列DevOps文章,我的看法是选择DevOps。
大家可以先从了解DevOps入手,我已经在之前的文章《DevOps生命周期,你想知道的全都在这里了!》中已经详细说明了。敏捷和DevOps毫无疑问可以共存,DevOps很多时候被视为敏捷的延申,将敏捷的理念扩展到代码部署之外。
那我们该如何在敏捷团队中启用DevOps?
01 放弃使用手动
手动流程是最常见的错误和延迟源头。在软件开发过程中,我们需要注意"手动"一次,包括手动测试、手动部署、手动交付......这些都是浪费时间的蛛丝马迹。
02 找到瓶颈
在整个流水线中实施检测,查看代码在哪些地方受阻,然后集中精力消除瓶颈。没有什么能比通过最慢部分的速度更快。管道中其他地方的改进只会让瓶颈变得更糟,因为它们只会在堵塞点堆积更多的任务。要想取得进展,唯一的办法就是解决最大的瓶颈。
03 自动化测试
这是实现真正有效的敏捷的关键因素。我听说它被描述为黄金标准,但并非绝对必要。错。自动化测试是绝对必要的。它能让你永远快速。人们喜欢说他们做的是测试驱动开发(TDD),但通常他们只是说先写测试再写代码。真正的TDD是自动化的。而有效的TDD是立即完成的。人们常说以后再写测试。这永远不会发生。
如果你打算这么做(你应该这么做),现在就做。不仅要自动化UI测试,还要自动化集成测试、单元测试和验收测试。是的,在功能代码之上编写测试需要更长的时间,但从长远来看,这不会拖慢您的工作进度。事实上,自动化回归套件能帮助你实现持续和无限的速度,正如《敏捷宣言》所设想的那样。试图用手动测试来实现敏捷是失败的秘诀。尽一切努力实现自动化,并不惜一切代价保护它。
04 使用自动化工具
在选择配置管理工具时,我们应优先考虑支持基础设施即代码(IaaC)的工具,这是实施DevOps理念的关键。这种方法能够方便我们在多种平台上部署应用,避免重复的工作。
提高自动化程度至关重要,包括大部分代码、扫描流程,以及预防任何潜在的Bug。我们应在存储库中构建工件,或者实施自动发布,以极大程度上减少基础设施和开发团队之间的协调工作。
同时,我们需要注重文档的记录。虽然在敏捷方法中,团队可能不会详细记录他们的会议纪要或其他交流内容,但在DevOps环境中,完整的设计文档和规范对于理解软件版本至关重要。
当然,企业转型DevOps难免会遇到一些"不可抗阻力"和"结果不尽如人意",禅道提供DevOps咨询课程, 帮助企业从持续集成、持续部署到自动化测试和监控的落地全方位DevOps流程。
既然我们已经知道了改进的方向,那么我们就该勇敢地尝试,最终形成能够持续交付和以客户为中心的团队,交付让客户满意的产品。正如培根所说:"世界上有许多做事有成的人,并不一定是因为他比你会做,而仅仅是因为他比你敢做。"
也不知道那位读者能不能看到我的回复!