上海建设网站的公司,标书制作简单吗,沧州网站建设推广,兰州网站制作cheng作者 | 文振熙、刘文沣责编 | 徐威龙封图| CSDN 下载于视觉中国商米科技成立于 2013 年#xff0c;总部位于上海市杨浦区创智天地#xff0c;是一家具有产品创新基因和互联网基因的公司。商米在短时间内迅速成长为一家近1000人的企业#xff0c;产品研发人数占比一度超过70%… 作者 | 文振熙、刘文沣 责编 | 徐威龙封图| CSDN 下载于视觉中国商米科技成立于 2013 年总部位于上海市杨浦区创智天地是一家具有产品创新基因和互联网基因的公司。商米在短时间内迅速成长为一家近1000人的企业产品研发人数占比一度超过70%。做为一家初创企业商米研发团队早期也经历过与当下大部分创业公司一样困境协作基本靠吼、发布基本靠手的阶段。然而业务的快速发展团队规模不断的扩大给商米带来了在「团队协作」和「工程效能」上的双重挑战。蒸汽时代为了能快速让团队进入步入正轨商米研发团队早期采取和大多数企业类似的组织方式以职能为单位的进行团队划分分为前端、后端、Android端、测试、产品等职能团队并采用传统瀑布研发模式组织团队协作。当时我们称之为正规的研发模式。每个团队由组长负责制具体负责团队任务的分配、技术决策和人员培养组员负责具体的研发任务。根据这样的职能协作的方式商米建立了早期的研发流程产品经理进行原型图设计然后产品经理分别找各个组长请求人员支持组长根据自己团队人员工作现状将工作安排给相应的同学接手产品开发任务完成工作量评估、给出截止时间等最后再各自团队的同学完成相应的工作之后大家约好一个时间集中联调一下再交付给测试团队。职能团队的组织方式帮助商米走出了第一步。但是彼时工程能力方面却是一穷二白别说CI/CD了连部署工作都还是手工FTP上传文件来进行服务器的发布。没有专门的运维团队服务器运维工作一直是后端团队承担发布又是一个很重要的动作出不的半点差错只能让后端组组长进行发布当业务不断发展项目数量不断增多负责发布的那个同学苦不堪言。没有专业运维团队没有现成的工具。只能硬着头皮去网上胡乱找一通Jenkins太复杂最后还不容易找到了一个简易的工具解决FTP上传的问题但最后的发布还是人工进行。小结通过建立职能团队产品经理对接职能团队寻找开发资源以瀑布方式组织交付工程能力方面采用FTP纯手工上传方式进行发布无专业运维团队。团队的不断增长和快速发展的业务又带来了新的挑战。团队间协作依赖团队成员业务归属感差同时因为手工为主发布软件通宵发布不是一件稀罕事。无论是协作效率还是工程能力上这种老牛拉破车的状态逼着商米团队进行转变。电气时代在寻找解决办法过程中商米向Teambition学习并引入Scrum研发模式尝试将职能团队改造基于业务线的跨职能团队资源独享组建独立业务交付团队每个团队都包含产品、测试、后端、前端、Android端跨职能采用Scrum工作模式引入Scrum Master 和四次Scrum会议计划会、每日站会、评审会议、回顾会议跨职能团队恰好能解决当时商米遇到的团队协作上的问题但却无法兼顾职能团队的优势于是增加技术委员会团队来支持业务交付团队通过敏捷化演进在团队协作上虚线和实线发生了变化这种方式同时给SUNMI带来了另外一个改善在成员评估上可以综合成果产出、工作状态以及技术能力多方面做出较全面的判断PO评估团队成员的业务成果的贡献SM评估团队成员配合过程中的积极性响应速度委员会评估团队成员的技术能力和技术水平。如组员张三的转正评估为了更好的进行跨地域协同数字化研发活动在协作工具上商米引入Teambition推出的敏捷模板能够对Sprint进行规划并且能够对迭代数据燃尽图进行分析。在缺陷管理方面也从Mantis切换到Teambition的缺陷管理和任务无缝关联。同时在文档协作上引入Thoughts工具建立了完善的知识库体系研发协作模式的改变给团队在协作效率和节奏上带来了真正的好处。团队再也不觉得自己是草台班子了而是真正具备一家科技公司该有的样子。这是技术团队在管理模式上的一次重大升级。小结采用以业务为导向的跨职能团队有效解决职能间协作的依赖问题同时增加团队的业务归属感以技术委员会从职能角度组织人员培养和技术决策落地Scrum研发模式让团队形成节奏感。商米经过敏捷转型解决了部分问题支撑了团队规模和业务体量的进一步扩大进入了新一轮增长期。除了支持企业内部的研发发布同样商米也在构建自己的研发生态圈按部就班的研发方式显然难于应对当前业务的复杂性和不确定性体量越来越大。同时随着产品服务化之后服务的数量持续增加。业务复杂性团队规模还是技术的复杂性和耦合性都给整个协作和发布效率带来了巨大的麻烦。看似繁华的背后却有着道不尽的心酸1、发布流程不规范发布频次低流程长时间久人工介入多容易出错漏测、搭车现像频繁没有验证完还不愿发的被发布了每两个月就有由于流程原因导致的故障2、信息同步不准确不及时任务的工作状态与发布流程割裂线上的事情线下做约定发不发不清楚发到哪不清楚不知道具体应用什么时候有谁做过发布各角色、各系统之间的信息分离3、检查及测试手段匮乏无检查无验证卡点测试后置检查验证手段有限测试手工兜底每次发布验证周期时间很长代码评审集中在少数人有瓶颈代码评审成为做样子漏发、漏测4、公地危机环境问题环境被长期占用总是不够用环境有脏东西不清楚是什么每次发布对业务有影响停机发布如何破成了商米技术管理者面前的一道难题。高铁时代1、加速交付加速的基础发布方式的提升一个偶然的机会接触到阿里巴巴云智能的云效团队我们决定联手解决商米当前面临的难题经过分析发现问题主要集中在以下几个方面返工批量的集成容易造成整个版本的失败每次失败所有的变更都跟着发不了。所谓一粒老鼠屎坏了一锅汤阻塞手工工序过多形成等待、阻塞依赖过多等待其他的部署落后的技术手工测试流水线手工串接及触发信息同步靠口口相传纯手工维护所有文档债务无测试自动化无有效的代码扫描手段无单元测试应用间耦合高分析完这些问题在云效团队的帮助下我们分别从整个流程和每道工序上进行了优化。通过行云/飞流工具套件商米解决了工程效能的问题第一步自动化部署流水线释放运维人力。一是对部署能力上进行自动化改造不再让发布成为瓶颈团队想发就发发失败了也有相应的自动化应急措施。另一方面在整个流水线上通过基于飞流提供的流水线模板快速创建了自己的流水线并同时进行了改造保存为企业自定义的流水线模板这样当有团队需要用到流水线时自动从模板上复用下来减少了配置和推广的成本默认从同一个模板上生成的流水线在规范上是一致的。第二步建立质量保障机制建立质量卡点防止低级错误漏出完善代码扫描、单元测试从源头控制质量同时通过飞流的Jenkins插件把我们之前基于Jenkins job的测试任务对接进来完善掉测试屏障。同时灵活卡点设置根据团队业务情况动态配置研发流程。与此同时我们直接采用行云提供内建的代码规约扫描和安全敏感信息扫描从实际上的效果来看直接在配置上打开就可以了还不错。如果采用非主流的开发语言可以把扫描做为流水线当中的一个阶段任务对接进行来就可以了。Code Review的能力同样采用了行云内置的功能代码的浏览和主流的云上编辑器差不多可以单行给comments并且可以将code review设置为强制卡点。团队code review的实践很容易在这个工具下进行。我们早期维护了一些自动化的测试用例一直都是通过Jenkins Job进行运行的采用飞流的流水线之后通过飞流的Jenkins插件也把之前的测试用例给跑起来了。第三步通过流水线的编排能力为业务交付团队提供发布部署顺序上的编排由业务交付团队自行控制发布的时间、顺序。团队不再依赖专职的运维同学帮助发布软件。运维团队也逐渐从发布工程师慢慢往SRE的路上发展。而之前都是需要开发工程师反复写好发布的说明由运维去执行。第四步整个流程可视化发布状态实时感知日志完善方便研发排查问题我们听过很多的方法接触过许许多多的实践但画在PPT上的流程难于落地写在书上的方法离我们太远。技术人在意的是实实在在解决问题将流程和方法内建在工具上是这次转变的最大收益。真正做到流程工具化、过程自动化、反馈数字化。工程能力的巨大的提升同时进一步促进了协作方式的转化。2、工程能力建设作用于协作方式的转变由于开发和运维在工作流程上割裂的原因在团队协作看板上也是割裂的彼此完全基于不同的单元在组织工作。两周的迭代第一周需要主要集中在团队开发看板上第二周发布请求主要集中在运维发布看板上。Scrum Master在开发团队的看板上刚组织完需求协作又得到运维看板上去协调发布请求并且建立发布请求与需求之间的关系当发布工作完全由团队自行决定后团队可以自行控制发布节奏很自然地融合了开发看板及运维看板形成完整的需求交付生命周期基于需求组织交付协作。引入飞流DevOps工具工程师可以直接从需求/任务卡片上创建变更分支自动就将代码变更与需求/任务卡片进行关联代码变更的提交同时自动地触发的流水线流水线的状态也同样会显示到开发看板中大大减少了信息同步过程花费的时间。真正做到基于一个团队开发看板就能可视化代码变更、发布流程所有信息将隐性的工作显性化进一步简化了信息同步促进了协作。每日站会开发者基于teambition进行需求或任务指派开发者基于需求/任务自动创建变更分支将需求的代码变更提交到变更分支在行云上采用内置的代码规约和安全扫描完成代码检查并发起代码评审代码评审通过自动触发发布流水线中间所有的代码变更、发布流水线状态全都自动同步到需求/任务卡片上保证需求上汇集协同所需要的全部信息。同时钉钉机器人将发布过程中的任何问题自动推送给开发者完全精确反馈。从2019年12月20号开始截止到2020年2月21日在短短三个月里SUNMI从零开始做到了从「蒸汽时代」到「高铁时代」的蜕变到现在使用Teambition进行任务协作共521名成员Teambition近期活跃项目49个使用Codeup管理138个Git项目3个月来共使用MR合并审核代码964次使用Flow管理120条发布流水线3个月来共运行过3910次成功上线771次平均每天65次构建12次生产发布。发布窗口期从周二周四演进到随时可发发布时间从数小时到一天半缩短到半小时以内交付速度从两周一次交付缩短到一天能够发布三次交付三个功能点或修复BUG交付到用户手中商米引入行云/飞流工具套件再加上协作方式的改变为整个商米软件研发效能带来了巨大的提升真正意义上的进入了“高铁时代”。从过去每周两次的发布窗口期改善为随时可交付部分团队甚至一天可以进行三次交付大幅节省了运维发布时间不再依赖人工操作和当面沟通团队内部可以在一个TB看板内关注到需求交付的全过程。小结优化部署流水线按工序持续完善质量保障为持续交付建立工程能力基础同时工程能力的提升也促进协作方式的改进。三个阶段小结从DevOps到SecDevOps不光要快还要安全。无论是真正的高铁还是DevOps。对于中小企业来说安全就是生命线谁也不敢在资产安全问题上掉以轻心。针对中小企业来说要完整地构建安全编码的能力缺少这样的实践同时也缺少比较好的规则引擎。我们采用行云内置的代码规约扫描把一般的编程中容易导致安全漏洞的代码给识别出来同时我们也通过一些敏感信息扫描来识别是否有把安全相应的信息给明文化出来。同时针对工具平台本身的安全同样采用行云和飞流提供的白名单设置权限管理等来提前做好安全的防控做到事前预防同时在过程工具平台还可以对一些异常行为如批量的代码转移或删除动作进行监控提前提出预警做到事中监控如果一旦发现有问题我们也可以利用平台的日志功能来做到事后追溯的目的。整体上来说这些安全的能力已经完全够用如果不想用到这些能力想用自己的话也可以disable掉接入自己的就可以了。不过我还是建议那些没有太多安全防控能力的企业直接采用平台内置的功能省得重复制造轮子。写在后面问题永远是创新发展的发动机。在商米走向DevOps的路上正是这样一个个的问题促使着他们去探索发现也正是这样每一次的探索发现在解决问题路上的那点小纠结、小成就、小雀喜让他们在解决问题的路上走得更坚定更有信心。希望商米的故事能够对你有一点点启发哪怕只是一点点。参考阿里云智能云研发团队《跨越敏捷企业DevOps解决方案》https://thoughts.teambition.com/sharespace/5e46536cb5d8ea001aa0d8a5/docs/5e4e7907281780001b935245作者介绍文振熙2015年加入SUNMI科技一直从事云计算研发管理相应岗位当前任职「SUNMI-云计算委员会主任」、「SUNMI-SBS业务线后端委员会组长」。曾推动SUNMI多次转型Go语言推广、全面SOA服务化、K8S容器化落地、Wayne自助平台以及《行云/飞流》CI/CD落地等。刘文沣2017年加入SUNMI科技从业务开发至前端研发管理现任职「SUNMI-SBS业务线前端委员会组长」。先后承担多次技术攻坚及推动技术演进ng1向react栈的迁移改造、基于webrtc的设备远控功能、 前端自动化构建及容器化部署、项目微应用化以及「行云/飞流」CI/CD落地等。声明本文为CSDN博主「喵了_个咪」的原创文章博文链接https://blog.csdn.net/u011142688/article/details/104859720。推荐阅读百万人学AICSDN重磅共建人工智能技术新生态突破性能极限——阿里云神龙最新ASPLOS论文解读漫画如何给女朋友解释什么是熔断
疫情期间天天对你“开枪”的额温枪你知道它的工作原理吗| 原力计划
如何更新你的机器学习模型手把手带你设计一个可持续的预测模型
区块链数据分析让你看清交易对手
真香朕在看了
