版本和配置管理
上一篇文章提到了,版本和配置管理要追求的目标是信息一致可追溯,版本信息标准化。
常用的版本和配置管理相关的工具,比如Ansible、Git、Apollo、CMDB等,都是被大家所熟知和广泛应用的工具,也是工程实践的一部分。工具和技术的选型根据各自的具体情况选择合适的即可,但其中有几点注意事项:
当然,无论是变更检查还是权限管理,都应该成为软件研发交付流程中的规范,尽可能强制执行。人的行为是无法完全控制的,不能指望员工的个人专业能力和职业素养是完美无缺的,流程规范的目的是为了收敛可能的风险。
频繁的编译构建和部署,是软件研发和测试阶段最常见的动作。很多时候我们的精力放在了code review、变更检查、冒烟测试和发现修复bug方面,但在和很多技术同学沟通后,我发现了一些被大家忽略的问题,那就是环境稳定性。
无论是编码、服务联调还是测试执行、发布前的验收,这些动作都是在具体的环境中开展。如果环境不稳定,就相当于在一个漏洞百出的小船上讨论如何遨游四海。
根据我的实践经验,在服务部署和环境管理方面,有以下几点需要引起重视:
持续集成和持续交付可以说是软件工程领域的一个重要实践,它提倡的是频繁的将团队成员提交的代码快速的进行编译构建,并且每次集成后自动进行自动化测试的验证工作,以期尽早更快的发现问题并快速修复。
但在实际的落地过程中,往往都会出现这几种典型案例:
为什么会出现这种情况,大量的单独的轮子是表象,背后的原因则是各自为战,没有将各个团队独立的轮子能力串联利用起来。比如运维开发了发布平台,测试高了一个自动化测试平台,基础架构的监控平台也是独立的。大家都在建设这种小范围的流水线能力,但在实践过程中,动作都是断开的。
在devops的落地实践中,我个人认为如下几点是衡量持续交付能力的几个重要特征:
还记得前面文章提到过的VSM价值流图吗?它最重要的特点是提供全局视角、快速识别问题、促进团队合作、驱动质量度量以及体现技术价值。VSM的几个关键要素如下:
在实际的研发测试活动中,很多时候我们的注意点在单元测试覆盖率、测试用例覆盖率、bug数等更容易量化的指标上,这些纯技术指标对于工作量的评估是有一定的借鉴,但工作量真的等于创造了有意义的价值吗?不一定!
同样,很多公司推行站会、早会、周会例会,也有类似看板的可视化大盘,但这些东西最后大多变成了向上汇报的PPT。可视化的目的是为了同步信息,降低信息差带来的无形成本,识别低效率环节并加以改善。持续度量是需要基于价值流来定义明确的有价值的目标,然后选择合适的指标和数值来评估研发过程,衡量交付结果。
可视化和持续度量,二者本身需要关联在一起,才能真正实现devops最本质的目标: