Azure DevOps ——创建项目 —— 版本和工作流进程的区别

之前说过了微软的 Azure DevOps 分为云版 Azure DevOps Service 和本地版 Azure DevOps Server,现在我们就开始来一点点教大家如何使用里面的几大模块。

Azure Board

看板,是敏捷开发里面对任务进行可视化管理的一种方式,几乎所有的敏捷开发管理工具都具备看板这种功能,可能大家最最熟悉的是 JIRA 了。如果你不了解敏捷开发,那么你可以跳过这一篇文章。

创建项目

如果没有项目,你当然得创建一个啦,如图所示:
在这里插入图片描述

项目名称

尽量不要使用中文来命名你的项目名称,因为…直接上图吧…

在这里插入图片描述
在 git 中的地址会被转义

你可以在描述中说明你这个项目的中文解释。

高级

这里有两个选项,一个是源代码管理,分为 Git 和 Team Foundation 版本控制(TFVC)。
在这里插入图片描述
Git 这个就不用说了,全世界的 Git 原理都基本是一样的,只不过有很多托管平台,比如最著名的 Github,Gitlab 等等,国内的码云,优快云 Code 等等。

Team Foundation 版本控制(以后称为:TFVC)可以说和 SVN 功能类似。

Git vs TFVC

英文好的盆友们直接移步 https://docs.microsoft.com/zh-cn/azure/devops/repos/tfvc/comparison-git-tfvc?view=azure-devops&viewFallbackFrom=vsts 看微软文档。

  • Git是一个分布式版本控制系统

每个开发人员都在其开发计算机上拥有源存储库的副本。开发人员可以在其开发计算机上提交每组更改,并执行版本控制操作,例如历史记录和比较,而无需网络连接。分支很轻。当您需要切换上下文时,可以创建一个私有本地分支。您可以快速从一个分支切换到另一个分支,以在代码库的不同变体之间进行转换。稍后,您可以合并,发布或处置分支。

  • Team Foundation版本控制(TFVC)是一个集中版本控制系统

团队成员的dev计算机上只有每个文件的一个版本。历史数据仅在服务器上维护。分支是基于路径的,并在服务器上创建。

简单来说,TFVC 要求客户端需要联网的情况下才能工作,因为代码是保存在服务器上的,只有联网你才能修改源代码,而且当某个人正在修改某个文件时会被占用,其他人需要等待其签入后才能修改。

他们都各有优势,虽然现在流行 Git 来作为源代码管理的引擎,但对于源代码保密性较高的企业,使用 TFVC 会比较好。

工作项进程

在这里插入图片描述
这里有三种工作流模板,这三种模式概念是不一样的,英文好的朋友可以移步 https://docs.microsoft.com/zh-cn/azure/devops/boards/work-items/guidance/choose-process?view=azure-devops&viewFallbackFrom=vsts 可以更快地获取知识。

云版提供了一个基本的工作流程,而本地版没有这个功能。

Basic、Agile、CMMI 和 Scrum 的区别
  • Basic(云版功能)
    在这里插入图片描述
    用 Issue 表示问题,用 Task 来跟踪剩余的工作。

  • Agile
    在这里插入图片描述
    当您的团队使用敏捷规划方法(包括Scrum)时选择Agile,并分别跟踪开发和测试活动。如果您想跟踪Kanban板上的用户故事和(可选)错误,或者跟踪任务板上的错误和任务,则此过程非常有用。任务支持跟踪原始估计,剩余工作和已完成的工作。

    • Epic
      在这里插入图片描述

    • Feature
      在这里插入图片描述

    • User Story
      在这里插入图片描述

    • Bug

    • Task
      在这里插入图片描述

  • Scrum
    在这里插入图片描述
    选择的Scrum当你的团队实践Scrum的。如果您想跟踪看板上的产品积压项目(PBI)和错误,或者将PBI和错误分解为任务板上的任务,则此过程非常有用。
    任务仅支持跟踪剩余工作。

    • Epic
      在这里插入图片描述
    • Feature
      在这里插入图片描述
    • Product Backlog
      在这里插入图片描述
    • Bug
      在这里插入图片描述
    • Task
      在这里插入图片描述
  • CMMI
    在这里插入图片描述
    当您的团队遵循更正式的项目方法时,选择CMMI,这些方法需要一个流程改进框架和可审计的决策记录。通过此流程,您可以跟踪需求,变更请求,风险和评论。此流程支持正式的变更管理活动。任务支持跟踪原始估计,剩余工作和已完成的工作。

    • Epic
      在这里插入图片描述
    • Feature
      在这里插入图片描述
    • Requirement
      在这里插入图片描述
    • Bug
      在这里插入图片描述
    • Task
      在这里插入图片描述

Agile 适合我们常用的敏捷迭代,Scrum 则真正的敏捷开发的工作方法,你可以阅读 https://www.cnblogs.com/vansama/p/5600986.html 来进一步了解他们的区别。

总结

本章介绍了在创建项目时遇到的一些问题和注意事项,同时也大致说明了源码管理的两种方式 Git 和 TFVC 的不同,介绍了工作流模板,它关系到你下面需要详细说明的 Azure Board 的概念以及项目的管理方式。

如果你已经说用了其他的项目或者敏捷管理工具,例如 JIRA,你可以忽略这一章。

### Azure DevOps 使用指南最佳实践 #### 项目管理与协作 Azure Boards 提供了一套完整的工具链用于敏捷项目管理工作项追踪。团队可以通过创建Backlog、Sprint计划以及使用看板视图来有效规划监控进度。为了提高透明度支持远程协作,建议启用实时更新功能并定期举行站会。 ```python # 创建一个新的工作项 from azure.devops.connection import Connection from msrest.authentication import BasicAuthentication personal_access_token = 'YOUR_PERSONAL_ACCESS_TOKEN' organization_url = 'https://dev.azure.com/YOUR_ORGANIZATION' credentials = BasicAuthentication('', personal_access_token) connection = Connection(base_url=organization_url, creds=credentials) work_item_client = connection.clients.get_work_item_tracking_client() new_wi = { "op": "add", "path": "/fields/System.Title", "value": "Sample Work Item" } response = work_item_client.create_work_item(document=[new_wi], project='YourProjectName', type='Task') ``` [^4] #### 持续集成(CI) 持续交付(CD) 利用Azure Pipelines可以实现自动化构建测试流程。定义YAML文件中的管道配置能够简化CI/CD设置过程,并允许版本控制下的变更跟踪。推荐采用多阶段发布策略,在不同环境中逐步验证应用程序质量;同时实施严格的权限控制措施以保障生产环境稳定运行。 ```yaml trigger: - main pool: vmImage: ubuntu-latest stages: - stage: Build jobs: - job: BuildJob steps: - script: echo Building the application... displayName: 'Build Application' - stage: Test dependsOn: Build condition: succeeded() jobs: - job: TestJob steps: - script: echo Running tests... displayName: 'Run Tests' - stage: Deploy dependsOn: Test condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main')) jobs: - deployment: ProductionDeployment environment: production strategy: runOnce: deploy: steps: - script: echo Deploying to production... displayName: 'Deploy To Production' ``` #### 安全性合规性 遵循最小特权原则分配角色服务主体权限,确保只有授权人员才能访问敏感资源。启用双因素身份验证(Two-Factor Authentication),并通过定期审查日志记录活动来检测潜在威胁行为模式。此外,还可以考虑参与社区贡献开源治理项目,共同维护完善安全标准。 ```bash az ad sp create-for-rbac --name "MyApp" --role Contributor \ --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group} \ --sdk-auth ``` [^2]
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

叫我 Teacher 周

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值