Azure DevOps | Boards、Pipelines

目标：

1. 掌握DevOps使用。包括工作项、冲刺、需求查看、任务的生命周期管理、管道、发布等。
2. 对项目组任务安排进行需求分析和任务工作项拆解、服务CI/CD发布。

Azure DevOps 是什么

是由微软开发的服务平台，它提供了多种工具，可用于更好地进行团队协作。它还具有用于自动构建过程，测试，版本控制和程序包管理的工具。

Azure DevOps 提供了 5 个主要模块：

1. Azure Boards：这些是敏捷的工具，可以帮助我们规划、跟踪和讨论我们的工作，甚至与其他团队一起工作。
2. Azure Repos：提供无限的、云托管的私人和公共 Git 存储库。
3. Azure Pipelines：使用适用于任何语言、平台和云的 CI/CD 进行构建、测试和部署。
4. Azure Test Plans：使用适用于应用的手动测试和探索测试工具来提高代码整体质量。
5. Azure Artifacts： 与整个团队共享来自公共源和专用源的 Maven、npm、NuGet 和 Python 包。以简单且可缩放的方式将包共享集成到 CI/CD 管道中。

Boards

Azure Boards 是 Azure Devops 提供的在线敏捷工具，进行敏捷规划和项目组合管理。使用面板、积压工作、冲刺、查询管理项目的用户故事、待办事项、任务、特性和bug，从不同维度不同方式组织各种 Work item，帮助您快速规划，管理和跟踪整个团队的工作。

1. 工作项：查看所有的需求、任务。需求要点进去才能查看到子任务，不能查看对应迭代的需求和任务，全部都是列下来，之间关系不强，适合从宏观上去看有多少工作，分配给谁的工作是什么状态了，什么状态的工作还有多少。
2. 板块：从业务流程来说需求。已建议、需求评审、需求冻结、UED、活动、SIT、UAT、待发布、已关闭。不单独显示任务。可以从迭代去选择查看。适合直观看这个迭代的需求到哪一步了。
3. 积压工作：和板块差不多，板块是板的形式，积压工作是一条一条的形式。一条需求，下边列着关联任务，到什么状态。
4. 冲刺：有任务面板，也有积压任务。任务面板中，按一个需求一个需求分，一个需求下边的任务到什么状态。冲刺里边的积压任务和积压任务差不多，一条一条，一个需求下有多少任务，到什么状态，但是有提测日期，SIT完成时间。

实际开发中使用

1. 看新迭代中产品增加的需求卡，了解自己相关的需求。开需求评审会，评审需求，把卡片状态从已建议到需求评审。

去冲刺中，看到积压工作中的需求。和自己相关的需求，做需求分析，拆解任务。开需求评审会，预估完成时间，填写提测时间。

2. 项目开发中如何用这个工具，先做什么，再做什么。开发做什么，产品做什么。

产品增加需求卡。开发去冲刺中，看到积压工作中的需求。找到和自己相关的需求，做需求分析，拆解任务。一起开需求评审会，预估完成时间，填写提测时间。

3. 任务的生命周期管理。

已建议(新建)、活动、已解决(已完成且需要测试)、已关闭(评审/测试通过)。

4. 需求的生命周期。

已建议(新建)、需求评审(评审会)、需求冻结、UED(用户体验设计)、活动、SIT(系统集成测试)、UAT(用户验收测试)、待发布、已关闭。

5. 敏捷、Scrum是啥意思。

敏捷是项目管理的一种方式，Scrum是敏捷管理中的一种管理框架。

6. DevOps生命周期分为以下七个阶段。

发展、集成、测试、部署、监控、回馈、运营

Pipelines

将源代码转换为可发布产品的多个不同的任务(task)和作业(job)通常串联成一个软件“管道”，一个自动流程成功完成后会启动管道中的下一个流程。这些管道有许多不同的叫法，例如持续交付管道、部署管道和软件开发管道。https://www.jianshu.com/p/804f449186e3

通俗理解

将开发部署环境生态链的每一步都通过pipeilne流水线串联起来，并代码化，开发人员一键就能将本地的代码发布到测试环境中进行测试发布，最终实现持续集成持续发布。

• CI持续集成（continuous integration）
  • 传统软件开发流程：多个开发者产生代码，并在发布前将他们的工作整合在一起。如果代码中出现问题或整合时产生问题，将不得不通过长时间的测试才可解决，之后才能正常发布，常常导致了软件品质问题和更新周期过慢。
  • CI：开发者对代码的每个修改都被迅速整合进软件的主分支(main branch)。CI系统自动运行测试以找出代码的问题，开发者得到了快速反馈并可尽快解决问题。一个新的功能只有在整合进主分支、与其他代码修改整合在一起，才被认为开发完成。目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。
• CD持续交付（continuous delivery）持续部署（continuous deployment）：
  • 传统部署新的软件发布曾经是相当有风险和复杂的事情。新的发布被测试之后，运营团队将其部署在生产环境。部署的过程可能会持续数小时，或数周，这取决于软件的规模、checklist和手动步骤以及对操作人员的专业要求。如果部署经常失败，会需要迂回方案(workarounds)或需要开发者的紧急支援。
  • 持续交付CD：用自动化的方式解决这些挑战。在CD方法中，软件被尽可能频繁的打包和部署到生产环境中。CD的核心原则是对代码的每一次修改被部署到生产环境中不会花费太多功夫。
  • 在CI系统整合代码变更并穿件系统的新版本之后，CD系统将新软件版本打包、部署在测试环境、自动化地测试运行效果，并将其推送到生产环境。最后的推送步骤由人工验证，但并不需要过多人工的工作。
  • 持续交付和持续部署都是CD，他们的区别在于开发者可以持续交付，但运营团队可以有选择性的部署或按批次部署。
  • 持续交付在软件开发过程中的目标是自动化、效率、可靠性、可重复性和质量保障（通过持续测试）。

实际开发中使用

1. 服务CI/CD发布，如何实际操作。

新建管道，写脚本，集成、发布、部署。

参考文章：
https://www.jianshu.com/p/804f449186e3