微软构建高效DevOps团队培训总结
Posted 海~~D
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微软构建高效DevOps团队培训总结相关的知识，希望对你有一定的参考价值。
9.21和9.22这两天参加了微软DevOps的培训，主要是围绕TFS2015的不少新功能来讲的，相比较之前我们一直使用TFS2013来管理团队，确实强大了不少，也更加实用了。
首先，什么是DevOps?
运维说主要是发布管理、CI持续集成的，开发说是开发测试一体化的，项目经理说是项目流程管理的。。。其实都没错，只是都不全面。百度百科上较严格的定义，不过它的似乎就是像开源社区一样，是经过大家集思广益，各自的经验方法总结而形成的一套覆盖软件开发运维流程的经验论。
目标人群
（第1天）企业研发经理，部门经理、团队经理与项目经理可以通过此培训了解到：
敏捷开发最佳实践分享，成功引入敏捷所需的企业文化变革，团队管理理念转换和对质量的全新理解；
DevOps研发流程落地项目的案例分享，了解研发全生命周期管理平台的持续价值交付能力。
（第2天）开发人员，测试人员，架构师，运维工程师和项目经理可以通过此参与此培训获得完整的敏捷团队开发体验：
参与培训的人员被组织成“领航员团队”，使用全生命周期管理平台实际进行为期2天的DevOps开发体验；
经过“领航员团队”培训的人员在回到本人的团队后可以作为领航员引导团队的日常开发工作，并指导团队进行改进。
了解一个项目从需求收集，规划，开发，测试到交付的全过程；
了解使用全生命周期管理平台支撑DevOps端到端过程和工程实践
了解使用容器技术构建持续交付管道(Release Pipeline)的最佳实践。
TFS可以为不同角色的团队成员提供不同的视角，将你关注的内容呈现在系统仪表盘上
项目经理仪表盘
以下视图展示了作为项目经理可以通过简单的配置实现的项目仪表盘，包括：当前迭代进度（燃尽图），团队成员，成员工作分布和进度，逾期任务，代码签入量，Bug趋势和项目总体进度。
开发仪表盘
TFS 也可以为开发团队提供专注于开发过程的仪表盘，如以下仪表盘为每个开发人员提供了个性化的视角来查看：未完成工作，我的Bug，我的任务进展，当前版本的测试执行时间和测试结果，以及每次CI的执行结果。
测试仪表盘
测试人员也可以建立自己独立的仪表盘，列出测试计划，测试执行情况，已经提交的BUG的进展情况以及测试结果分析。
Configuration as Code 基础架构即代码
这里印象深刻，把需要部署的环境封存成DLL或jar包，给我的代码来结成，最后即使是一个新的环境，也可以通过发布包代码直接部署。概念很超前，不过很多大公司的运维已经再用了，Docker——官网就是 Docker - Build, Ship, and Run Any App, Anywhere
质量
传统模型是基于左边的，而敏捷软件开发强调的是右边这张图，在一定的约束条件下，为了获得有价值的产品，只能牺牲相对的质量。
质量这个概念因人而已，需要分特定的条件。譬如说一款软件，某一个功能一直被用户抱怨，但确实是一直被用户实用的最多的功能，而另一个功能，用户从来没有抱怨，实则用户从来不用。所以质量在一定的环境条件范围下，是可以被牺牲的。这就好比行走的骨骼，抓住重点。
敏捷的质量
敏捷不一定保证一定就是快速开发出一条软件，相对的，它可能会更加复杂。它能保证给你的是优秀的软件质量和优秀的团队。Scrum的根本目标是提高质量，而不是满足时间和成本要求！
误解：敏捷开发是为了快速交付？
敏捷开发不是一种为了快速交付而出现的方法，它之所以比较快则是因为避开了许多浪费的处理方式。
影响地图Impact Mapping
一个价值导向的实践方法，透过可视化的方式, 建立商业目标与产品功能的关系, 以及背后关联的假设.
举了个琅琊榜的列子
以目标为导向
它主要解决的是
一、业务部门及开发部门之间的理解、沟通、协调及隔阂。
二、目标到功能间联系的模糊和不一致。
影响地图可以作为用户故事地图的输入
用户故事地图User Story Mapping
透过可视化的方式, 建立用户场景与技术规格之间的联系，并辅助团队有效沟通。
靠谱的想法到落地的计划
创建用户故事地图(User Story Mapping)的8个步骤
第一天的重点除了介绍DevOps概念，就是讲解了如何产生需求，如何讲用户故事。通过两种方法影响地图Impact Mapping 和用户故事地图User Story Mapping。感觉主要内容是给管理者和业务产品的。
第二天的内容主要是讲Scrum敏捷开发流程和CI持续集成。
重点强调一下完成规范
静态代码检查(SonarQube)不能完全替代Code Review还是需要人工来验证代码的逻辑和架构等。
关于Code Review，TFS的sourceControl由于branch策略不同，所以需要签入之前发给某人验证。而Git可以签入后去评审，由分支策略导致，签入后合并前。
剩下的就是做实验，演示用TFS做CI.
(部分内容摘自徐磊老师的PPT和相关博客文章)
相关链接:
用户故事地图(User Story Mapping)之初体验
以上是关于微软构建高效DevOps团队培训总结的主要内容，如果未能解决你的问题，请参考以下文章
大规模开发团队如何实现DevOps转型？ 来自微软全球开发平台工程团队的实践经验