Case Study

HAND

Better Experience

icon

Overview

汉得成立至今,作为一家在咨询实施行业服务超过20年的企业,服务各行业的客户超过3000家,业务领域已扩展至全面的企业信息化应用产品研发、咨询实施与技术服务。从智能制造到互联网行业再到传统的服装零售等方面都有涉及。

但是随着IT技术发展和经营环境的不断变化,企业表达出越来越多的个性化IT诉求。当需求越来越多样化,什么样的方式可以更好更高效满足客户需求?这是研发中心一直关注的问题,研发中心希望能以更高效稳定的方式实现客户需求。

Challenge

传统的瀑布模型开发方式强调预见性,各阶段之间具有很强的顺序性和依赖性,前一阶段的工作结束后才能开始下一阶段的工作,经常在规定时间内只有40%的项目能成功交付,而且开发时间如果过长,留给测试时间不够,质量上就无法得到保证。这种模式下越晚集成越容易失败,有时候实现的50%需求,无用需求占比却高达60%,很大一部分时间都浪费在没价值的事情上。而且当开发过程中新人比较多的时候,经常会因为环境导致编译发布过程中出现问题,会消耗很多时间,往往这些问题出现的时候,需要一些经验丰富的人去解决,最后确发现很多问题都是因为环境的不一致或是很小的差异引起的,想达到高效,就必须做出一些变革。 

Collision

 IDC曾对2000位跨国企业CEO做过一项调查,结果显示其中有67%的人认为,截止2017年底,数字化转型将成为所在企业的战略核心。预计到2018年底,全球有超过50%的大型企业将拥有完善的数字化转型战略。互联网已经带来了新的经济形势,在以技术为核心的商业模式下,必须要不断激发自己的潜能,而数字化转型的本质,就是通过技术变革来释放价值、激发潜能的过程,这也是研发中心所追寻的。

"在数字化转型的大背景下,我们一直也在寻求一个更好的软件开发方式,缩短我们的开发周期,更快地交付。我们是在做devops转型,但其实我们Devops转型过程是'不正统'的,回望这个devops转型,并不是有意去做转型,而是真的发现了很多传统开发管理过程中存在的问题。"

- 研发中心总经理 张礼军

说到工具链,研发中心在工具上有一个逐步演变的过程,例如持续集成,就用过很多工具,最初工程实践用的Jenkins,后来随着服务架构转变,发现Jenkins的特性并不适用于DevOps流程,就逐渐开始把基于GO语言实现的gitlab CI作为持续集成的工具。微服务架构,服务数量很多,如果按照原有方式,很难管理,但是容器技术恰恰可以解决这些问题,研发中心考虑过swarm,Rancher,Mesos,因为考虑到语言和开发工具统一,以及灵活性等各个方面,最终决定引入kubernetes来解决微服务架构所带来的问题。

对于服务的管理、发布,当服务越来越多,一个数据中心必须要有相应的持续交付来配合。为了更快地做好应用部署,要实现从infrastructure层来屏蔽它的复杂度和统一它的标准。企业内部要构建业务转型创新平台,必须具备devops,微服务,容器这些技术,才能满足这种业务创新技术平台的要求。基于这些,研发中心把支撑自身研发的团队能力转变成了一个平台的能力,逐步形成所说的数字化平台——PaaS(平台即服务)平台,总的来说,即把自身内生的需求逐渐演变成了一个产品,为其他客户提供Paas解决方案。

Choerodon的使用确实在很大程度上缩短了开发周期,加快了迭代的速度,大大减少了开发运维人员的负担。

研发中心现在已经在使用自研发DevOps平台——Choerodon,平台工具的使用确实在很大程度上缩短了开发周期,加快了迭代的速度。单体运用场景下,耦合度很高,开发和维护的成本很高,稳定性不好,很容易牵一发而动全身。如:之前是采用手动部署,需要配置各种参数,几个参数的时候还好,当配置项数目有十个或者几十个的时候,很容易出错,花费了大量时间找部署失败的原因,可能只是因为环境参数没有注入,时间成本很高。现在无需考虑这些配置项,大大减少了开发运维人员的负担。

研发中心将DevOps平台放入解决方案中,旨在帮助企业实现快速转型,目前已经开始与一些客户合作。

部门本身也在进行DevOps转型,同时也正在说服更多部门转向基于该平台的开发和工程实践。研发中心有很多软件开发人员,可以为他们提供平台作为服务解决方案,希望在他们的迭代周期中看到明显的削减以及开发运维一体化的真正实现。研发中心并不是把DevOps转型当成一种目标,因为对于传统应用来说,并非全部都适合,如何快速实现转型才是最终主旨。

研发中心不仅是供应商,同时也是用户,可以在用户的角度来看待这个产品,总结自身在使用过程中的遇到的问题,不断对产品进行持续优化,相比于只作为开发者,相信会带来更好的用户体验。