团队项目-代码管理准备

罗杰 2023-03-07 18:28:18

“Your organization’s codebase is sustainable when you are able to change all of the things that you ought to change, safely, and can do so for the life of your codebase.”

——Software Engineering at Google, Titus Winters, Tom Manshreck and Hyrum Wright

课程的团队课设最终要求大家交付一个完整可用的软件系统。时长两个月的团队开发中，我们将时时对团队最重要的资产——代码库进行修改、迭代和完善。因此，保障它稳定、安全、可持续地存在，并能够稳健地持续合并来自每个成员的变更、扩展和迭代是重要的。

我们可以采用无数种可能方式来管理这一资产：基于Q〇群文件分享代码压缩包会得到助教组充满敬意的赞👍、邮寄代码的完整纸质副本会在这门课程的历史上留下足够先锋的脚印👣......但如果你也一样，对 软工课堂展示-Pre-Draft5By熊-ffffffinal最终版真的绝对不再改了.pptx 这样的文件名抱持与生俱来的恐惧、又或是憧憬无纸化办公的环保主义者，那么在团队开发中引入版本控制系统（Version Control System, VCS），绝对是值得的投资——事实上，也是当下软件工程领域明确的共识。

软件工程是随着时间的推移而集成的编程......开发本质上是一个分支和合并的过程，无论是在多个开发人员之间还是在不同时间点的单个开发人员之间进行协调。

多人、长时的开发流程，需要正式的版本控制系统来管理源代码、协调工程师之间的活动。团队开发的过程中我们会自然地产生如下需要：

  • 追踪工作的最新进度和历史进展；
  • 并行地进行工作，提交更改；
  • 合并修改、跟踪合并；
  • ......

为了支撑这些需要，除了将 VCS 集成进我们的工作流程之外，我们还需有一套共识性的规范来指导对 VCS 的使用——团队开发中对代码库负责的不是某一个人，而是每一个人。

在这篇 Guide 里我们将一起通过一次团队的实践，认识版本控制系统在集体开发中的具体做法，并对形成行之有效的协作规范有所见解。

版本控制系统的选择有很多，你可在这里进一步了解。这篇 Guide 基于目前最流行、也是大家最可能选用的分布式版本控制系统 Git 设计。

需要做什么？

附录 A 提供了一个软件工程小组的 Git 规范。接下来会给定一些任务，请依据指引遵照这份规范来进行代码修改和 Git 操作。

请注意，这份 Git 规范并不是团队开发的最佳实践，在不同的情形下、不同的团队中需要针对各类因素来设计适用的规范和工作流。我们基于这样一个目标采用了这份规范并设计了这次作业：涵盖团队开发阶段使用版本控制系统时可能遇到的常见场景和具体问题，从而让大家对这些问题有基本的认识、进而制定和协调最适用于各自团队的工作流。

助教组会根据 commit 记录等仓库遗留的操作记录检查每个团队的完成情况。

请保留全部的操作记录，包括分支、issue、pr 等。

当你的操作出现不致命的小差错、与“规范”相悖时，不用担心，这些无心之过可以原样保留在操作历史里。但是，“觉得自己搞砸了”的情形下，希望你能在代码仓库根目录下的 error-logs.txt 中留下你对错误的记录。

如果出现团队成员误操作、导致难以还原的情况，请首先了解可能的恢复方式、或在课程群中讨论有关做法，在完全无果的情况下可以重新开始。再次提醒大家：团队开发中对代码库负责的不是某一个人，而是每一个人，请谨慎地对待这份团队最重要的资产。这些情况，需要在作业提交时记录。

助教组可能会根据记录情况询问团队相关问题。

任务列表

请按照顺序完成各组任务。同组内无序列表标注的任务没有严格的顺序。

标记为 🚧Maintenance 的任务请团队中的特定成员负责，通常可以由小组中的 DevOps 岗完成——当然，也可以分配工作给某几位同学一起完成；

标记为 🧑‍💻Every 的任务请团队中的每一位成员参与；

标记为 🚩Team 的任务请团队将列表中的任务分配给各位成员完成，每位成员至少完成一项、一个任务只能分配给一个人完成。

PRE. 团队的准备

🧑‍💻Every 团队协作的事前讨论

  1. 请大家在一起讨论对于 DevOps 的理解，分配本团队的 DevOps 相关工作。操作上，也可以由团队决定一位同学来担当全部相关工作。
  2. 请大家调研并根据小组内的网络环境、使用习惯等因素决定 DevOps 的各项考虑和服务选型，也可以使用一体化的 DevOps 平台例如腾讯云 CODING. 至少，需要决定一款代码托管平台。对于这次作业，请在 GitHub 或 GitCode 中二选一完成。
  3. 选择好之后，请各位成员在相关平台上完成账户注册、创建组织等工作。请注意，本次作业的代码仓库需要保证至少课程组内部可以自由访问以保证公正性；除非特殊情况，建议保持公开。

🚧Maintenance 初始化代码仓库

  1. Fork（或在使用其他平台时 Clone）GitHub 仓库 或 GitCode 仓库，初始化本团队的仓库；
  2. 设置代码仓库中成员的相关权限；
  3. 建立一个 dev 分支；
  4. 检出分支 chore/init；
  5. 在根目录下创建一个 .gitignore 文件，忽略根目录下的 info.txt 文件；
  6. 在根目录下创建一个 error-logs.txt 文件；
  7. 为仓库设置 Issue 模板，你可以参照 GitHub 教程，或 GitCode 教程；
  8. 提交更改，按照合并规范操作，最终合并你的更改到 dev 分支；
  9. 通知团队的所有成员现在可以开始进入下一个阶段 Task.1 了。

Task.1

🧑‍💻Every 自我介绍！

  1. 每位成员：拉取代码仓库到本地；

  2. 在根目录下新建一个 info.txt 文件，向其中添加如下信息：

    name: <你的用户名>
description: <你的一句话自我介绍>

    请注意不要包含太敏感的个人信息。

🚩Team 各写各的！

  1. 接下来的任务，模拟开发中的各种情形，所有操作在 /src 下完成。提醒：请注意分支和提交规范。

  2. 请认领如下任务中的至少一项：

    • 新建文件 frontend.json，格式如下：

      {
    "data": [
        {
            "name": "<名称>",
            "link": "<链接>"
        },
            ...
    ]
}

      列举至少三个你所了解的前端框架。

    • 新建文件 backend.json，格式如下：

      {
    "data": [
        {
            "name": "<名称>",
            "link": "<链接>"
        },
            ...
    ]
}

      列举至少三个你所了解的后端框架。

    • 新建文件 midend.json，格式如下：

      {
    "data": [
        {
            "content": "<内容>",
            "language": "<语言>"
        },
            ...
    ]
}

      列举至少两条你所了解的双关 / 谐音冷笑话。

    • 修改文件 tga-awards-2022.json，文件内记录了几项 2022 年度 TGA 大奖的获奖作品，其中有一项似乎记载错误。这是一个 BUG，请按照 Bug 提出与修复 的规范进行修复。如果获奖结果和你的喜好不一致，你也可以声称某一项是 Bug 并修改为你喜欢的。

    • 修改文件 golden-melody-awards.json，文件内记录了近些年金曲奖的年度专辑奖获奖信息，其中有一项似乎记载错误。这是一个 BUG，请按照 Bug 提出与修复 的规范进行修复。如果获奖结果和你的喜好不一致，你也可以声称某一项是 Bug 并修改为你喜欢的。

    • 修改文件 anime-list.json，文件内记录了一些数据。原本的记录方法是：

      {
    "data": [
        {
            "name": "<名字>",
            "en-name": "<英文名字>"
        },
            ...
    ]
}

      助教派来的 PM 路过瞅了一眼，拍了拍脑袋，觉得太长了，需要重构成如下形式：

      {
    "data": {
        "names": ["<所有名字>"],
        "en-names": ["<所有英文名字>"]
    }
}

      请你不跟 ta 一般见识，帮 ta 完成这个微不足道的梦想。

    • 修改文件 really-ugly-json.json，代码风格差强人意，请你帮忙调整代码风格（不影响语义）。

  3. 当你完成任务后，提交更改（aka. git commit）；

  4. 按照合并规范操作到提出 Pull Request；

  5. 全员完成后进行到下一阶段。

🧑‍💻Every 第一次合并！

  1. 请大家在一起讨论你们如何进行 Code Review、如何处理团队产生的 Pull Request；
  2. 请大家完成本次任务中所有产生的合并，如果产生了冲突请讨论为什么会产生冲突、应该如何解决。并且讨论附录 A 中的合并规范可能出于什么原因要求采用 git rebase，而没有提到我们更为熟悉也一如其名的 git merge，这样的选择会带来什么样的问题和益处？可以参考这篇文章来了解相关信息；
  3. 请大家根据分支规范完成发布前的确认、版本发布和Tag 操作。然后，请根据你们的实践结果在一起讨论完成一次迭代后，你们如何完成代码的确认和发布。

Task.2

🚩Team 各写各的！

  1. 接下来的任务，所有操作均在 /src/info 下完成，其中预置文件的格式均相同：

    {
    "username": "<用户名>",
    "data": "<数据>"
}

    请保留格式，只修改内容;

  2. 请认领如下任务中的至少一项，每位同学领取的任务不能相同，先不要着急完成：

    • 修改文件 music.json，将内容修改为你的用户名和你最喜欢的歌名；
    • 修改文件 movie.json，将内容修改为你的用户名和你最喜欢的电影名；
    • 修改文件 anime.json，将内容修改为你的用户名和你最近印象最深的番剧（aka. 动漫作品）；
    • 修改文件 game.json，将内容修改为你的用户名和你最喜欢的游戏名，只改用户名也没关系；
    • 修改文件 food.json，将内容修改为你的用户名和你最喜欢的食物；
    • 修改文件 TA.json，将内容修改为你的用户名和你最喜欢的助教：这一项真的不会影响分数、只跟某人的心情有关；
    • 修改文件 pl.json，将内容修改为你的用户名和你最喜欢的编程语言。

  3. 认领好任务后，请在此时一次检出新分支，对应你选择的一项，命名为 feature/type-1，type 对应你选择的那项任务，例如 feature/food-1；

  4. 仍然不要开始完成任务，回到第二步，认领你第一次没有选择的一项，每位同学领取的任务不能相同。然后再次进行第三步，这次将分支命名为 feature/type-2；

  5. 现在可以开始完成你所选择的第一项任务了。请在 feature/type-1 分支上操作，完成修改之后，提交一次更改（FYI, aka. git commit）；然后再次修改 <数据> 项的内容为其他内容，再次提交一次更改。接下来，执行合并规范至提交 Pull Request。等待，不要开始第二项任务；

🚧Maintenance 第一项任务，完成！

  1. 请按照你们团队的 Code Review 和 Pull Request 处理流程，由有仓库管理权限的成员完成第一项任务所做修改的所有合并工作；
  2. 解决掉所有 Pull Request 后，请仓库管理者通知大家可以进行第二项任务了。

🚩Team 各写各的！

  1. 请完成你所选择的第二项任务。请切换到 feature/type-2 分支，完成修改之后，提交更改，然后再执行合并规范，如果此时你遇到了冲突，请解决每一个冲突：如果有来自他人编辑的信息，出于尊重请你把信息合并成：

    {
    "username": "<他人的用户名>, <你的用户名>",
    "data": "<他人的最新数据>, <你的数据>"
}

    的形式；

  2. 按照合并规范操作到提出 Pull Request，然后不用再等待，请团队的代码管理成员 🚧Maintenance 尽快处理 Pull Request，使修改合并到 dev 分支。

🧑‍💻Every 第二项任务，完成！

  1. 请大家在一起检查最终完成的 dev 分支代码，是否出现了修改丢失的状况。如果有，是谁的什么操作导致的？
  2. 请讨论在哪些地方遇到了冲突，如何解决，有没有意料之外的状况，应对这些状况进行了哪些操作。如果在合并 Pull Request 的阶段遇到了冲突，请讨论冲突的缘由。作为参考，可以在完成后的代码仓库下执行命令 gitk，对照显示的分支图进行讨论；
  3. 请大家根据分支规范完成发布前的确认、版本发布和Tag 操作，发布第二次迭代后完成的版本。

Task. HotFix!

🧑‍💻Every 超烫手的修复！

  1. 请大家一起完成以下任务，或许只需要一个人来操作，但需要所有人了解操作的流程。

  2. 请设想这样一个场景：在发布前检查中你们发现 /src/tofix/classdata.json 存在 Bug：由于助教的某种疏忽，任课老师的名字打错了！请依照分支规范的说明，在 release 分支上进行修复；

  3. 请设想这样一个场景：在将代码开源之前，你们突然发现 /src/tofix/SUPER-SENSITIVE-DATA.txt 含有某种绝密信息！而该文件（和它的信息）已经出现在远端仓库（的许多许多次提交）中了。请先 Clone 一份你们的仓库来避免惨剧发生，然后根据这篇指引执行操作，将这个文件从所有提交中移除，然后在远端新建一个代码库，将你们完成操作的结果推送到新的代码库。务请注意：这个文件是在你们开始修改前被不怀好意的助教引入的，请检查仓库中你们开始本次作业以前的各次提交，查找文件在被移动到这个位置之前还在哪里出现过，对应又该如何执行操作。

    找不到也没关系啦！但请一定要注意清除敏感数据时要考虑到文件或许被移动或改名而存在于其他路径的状况。

Task. Conclusion

🧑‍💻Every 写字！

  1. 作为作业的终点，请在团队博客上提交一篇博客，内容至少包括：

    • 团队的代码仓库地址；
    • 团队完成 Task. HotFix! 后新建的代码仓库地址；
    • 需要说明的状况。

  2. 同时，推荐团队完成以下内容，这部分内容在之后的团队项目博客作业（具体来说是项目展示部分）中仍然需要完成，因此现在完成可以减少之后的负担：

    • 团队选定的 DevOps 技术选型以及选择的原因、使用相关技术的方式；团队对代码仓库的管理、对这方面工作的安排；
    • 团队对于代码审查的考虑，代码发布的流程；
    • 在代码管理中，团队会遇到哪些风险，如何解决这些风险；

  3. 最后，如果确实有所心得，希望团队能记载过程中种种实践和讨论的所得，梳理一下，这些心得可能包括：

    • 这次实践中遇到了哪些问题，如何解决和避免；
    • 版本管理系统的协作中，除了使用软件之外，还需考虑哪些内容：例如，流程、规范等；
    • 适用于你们团队的版本管理系统协作规范；
    • 对具体软件操作的理解：例如上面提及的 git merge 和 git rebase；

    等等，这些内容不一定要留在博客中，更不参与计分，但一定会成为团队实践和个人软工路上的宝贵财富。

附录 A

一个软件工程小组的 Git 规范。

这份规范由 roife 在 2022 级北航软件工程的团队开发中编写。

⚙ 提交规范

Commit Message

<type>(<scope>): <subject>

<body>
  • type 有下面几类
    • feat 新功能
    • fix 修补bug（在 <body> 里面加对应的 Issue ID）
    • test 测试相关
    • style 代码风格变化（不影响运行）
    • refactor 重构（没有新增功能或修复 BUG）
    • perf 性能优化
    • chore 构建过程变动（包括构建工具/CI等）
  • scope（可选）：影响的模块
  • subject：主题（一句话简要描述）
  • body（可选）：详细描述，包括相关的 issue、bug 以及具体变动等，可以有多行

例子

[feat](账号模块): 增加微信登录验证

[fix](管理员 UI): Safari 下界面适配

1. xxx 元素 yyyy
2. aaa 页面 bbbb

Issue: #3

[refactor](招聘信息接口): xxx 接口更新

[style]: 格式规范更改，重新格式化

请不要用 fix #3 之类的 message 关闭 Issue！请按照 BUG 提出与修复的描述用 Pull Request！

🎋 分支规范

代码仓库分为以下六类分支：

  1. main 分支 线上在跑的版本
    1. 提供给用户使用的正式版本和稳定版本；
    2. 🏷️ 所有版本发布和 Tag 操作都在这里进行；
    3. ❌ 不允许开发者日常 push，只允许从 release 合并。
  2. release 分支 将要上线的版本
    1. 从 develop 分支检出，只用于发布前的确认；
    2. 允许从中分出 fix 分支，修复的 commit 需要 push 回 dev；
    3. ❌ 不允许开发者日常 push，只允许从 dev 合并。
  3. dev 分支 日常开发汇总
    1. 开发者可以检出 feature 和 fix 分支，开发完成后 push 回 dev；
    2. 保证领先于 main；
    3. ❌ 不允许开发者日常 push，只允许完成功能开发或 bug 修复后通过 pull request 进行合并。
  4. feature 分支
    1. 从 dev 分支检出，用于新功能开发；
    2. 命名为 feature/name，如 feature/resume_generation；
    3. 开发完毕，经过测试后合并到 dev 分支；
    4. ✅ 允许开发者日常 push.
  5. fix 分支
    1. 从 dev 或 release 分支检出，用于 bug 修复（feature 过程中的 bug 直接就地解决）；
    2. 特殊情况下允许直接从 main 直接开 fix 分支进行修复；
    3. 命名为 fix/issue_id，如 fix/2 ;
    4. 修复完毕，经过测试后合并到原来的分支（dev/release/main），并且保证同时合并到 dev;
    5. ✅ 允许开发者日常 push.
  6. chore 分支
    1. 从 dev 分支检出，用于各项修正，如重构、风格优化等；
    2. 命名为 chore/name，如 chore/resume_generation；
    3. 开发完毕，经过测试后合并到 dev 分支；
    4. ✅ 允许开发者日常 push.

🧬 分支合并

不许在别人的分支上开新分支，只能在主分支开分支。分支粒度可以尽可能小。

合并到 dev 分支

我在 my_feature 上开发了一段时间了，想要合并到 dev，可以这么做：

  1. 拉取最新的 dev ；
  2. rebase 当前分支到 dev，并且解决 rebase 带来的问题；
  3. rebase 完成后，将当前分支推到远端（TA注：请考虑一下这个推送的操作要在什么条件下进行），在 GitHub 上发起一个到 dev 的 Pull Request，及时合并，防止更多冲突。

想解决 dev 上和我有冲突的新提交，但是不想合并到 dev

假设我在 my_feature 上开发，其他人开发的功能上线到 dev 分支了。

那么我可以在当前的分支下 rebase 一下 dev 分支，这样我这个分支的几个 commits 相对于 main 还是处于最顶端的，也就是说 rebase 主要用来跟上游同步，同时把自己的修改顶到最上面。

开发的时候，如果你的功能很复杂，尽量及时 rebase 上游分支，有冲突提前就 fix 掉。

这样即使我们自己的分支开发了很久，也不会积累太多的 conflict，最后合并进主分支的时候特别轻松。

反对从主分支 checkout 出新分支，自己闷头开发，结果最后合并进主分支的时候，产生有一大堆冲突。

最后，不要在公共分支（例如 dev/main）上瞎 rebase！

🪳 BUG 提出与修复

  1. 提出一个 issue，按照 template 简要记录 bug 相关的信息，事后能看懂即可，不用太详细；
  2. 开一个 fix 分支，对 bug 进行修复。fix 修复完成后需要进行测试，确认已经修复；
  3. 开一个 pull request，并将 pull request 和 issue 关联起来；
  4. 合并 PR。

❌ 不要在 commit message 里面用 fix #3 等直接 close issue，应该在 pull request 关联 issue.

如果是在 feature 分支开发过程中遇到的小 bug，可以直接顺手本地修了，不用按照这个流程来。

附录 B

Git 的基本操作

我们预设大家已经通过既往课程对 VCS 有了基本的认识、并熟悉个人代码管理的基本操作。如果你不具备相关的背景知识，这里提供如下链接供你参考：

参考

这篇 Guide 参考了 Git 团队协作 和 Google 软件工程。对于前者，请寻找出版商购买；对于后者，你可以线上阅读中文版或英文版。

这里还有一些参考文章以备阅读：

实用工具

Ver.2 by @KumaXX

...全文
938 回复 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
0人已提交
完成率0%
暂无数据
回复
切换为时间正序
请发表友善的回复…
发表回复
JIRA 从入门到精通.doc
《JIRA 从入门到精通》，doc 格式，大小 2.9MB。图文并茂，手把手教你学习 JIRA。 内容预览： JIRA入门到精通 ——hjjlearning,2008.06.27 第一章、 JIRA介绍 跟踪并管理在项目开发和维护过程中出现的问题(如：缺陷，新特性，任务，改进等)是项目管理很重要的任务，但是很少有团队能做的很好。JIRA作为一个专业的问题跟踪系统可以帮助您把缺陷管理起来，让跟踪和管理在项目中发现的问题变得简单，而且充分利用JIRA的灵活配置和扩展性，可以将JIRA作为一个项目管理系统或者IT支持系统。 JIRA特性 1、 管理缺陷，新特性，任务，改进或者其他任何问题 2、 人性化使用的用户界面 3、 灵活的工作流定制 4、 全文搜索和强大的过滤器 5、 企业级的权限和安全控制 6、 非常灵活的邮件通知配置 7、 可以创建子任务 8、 方便的扩展及与其他系统集成：包括email、LDAP和源码控制工具等 9、 丰富的插件库 10、 项目类别和组件/模块管理 11、 可以在几乎所有硬件，操作系统和数据库平台运行 JIRA角色： JIRA作为一个缺陷跟踪管理系统，可以被企业管理人员，项目管理人员，开发人员，分析人员，测试人员和其他人员所广泛使用。 1、 管理人员： 根据JIRA系统提供的数据，更加准确地了解项目的开发质量和状态，以及整个团队的工作效率 2、 项目管理者 可以针对登记进JIRA系统中问题，进行评估，分配缺陷；还可以通过JIRA系统的统计报告了解项目进展情况以及团队的工作量，工作效率等信息。 3、 开发人员 在JIRA系统中查看分配给自己的问题，及时进行处理，填写处理情况并提交工作量记录。 4、 测试人员 根据测试情况，在JIRA系统中及时快速的记录问题并对开发人员处理后的问题进行验证和跟踪。 第二章、 JIRA安装 JIRA是一个简单易用的Issue管理和跟踪的工具，运行在JAVA平台上。下载和安装都很容易，按照安装文档，只需要十几分钟就可以搞定，而且还可以为JIRA配置单独的外包数据库(可以使用的数据库有MySQL、MS SQL、Oracle等)。 安装好之后就首先要在服务器上通过http://localhost:8080来对服务进行配置(8080是jira的缺省端口)。具体经过三个配置步骤就完成了： 第一个步骤是配置JIRA系统的属性： 第二步骤是配置JIRA系统管理员的信息： 第三步是配置JIRA系统的邮件通知参数 第三章、 JIRA管理使用 一、 Projects：项目 1、Projects—> Projects点击进入到项目列表，点击ADD Project后输入项目名称(name),关键字(key)，选择开发项目负责人(lead Developer)，填写描述（Description），通知计划（Notification Scheme），许可计划（Permission Scheme:）和问题安全策略（Issue Security Scheme）如图所示： 2、Project Categories点击进入到项目类别，如下图所示，填入新项目类别名称和描述。 二、 Users&Groups 1、 User Browser：用户管理，在页面中可以看到所有注册的用户，可以根据条件查询特定注册用户。如下图： 单击“Add User”，添加新用户，输入相关用户名，密码，邮箱等，如下图： 点击create后，可以设置注册用户的权限组，修改用户信息，或更新用户密码，删除用户等操作。如图： 单击Edit Groups可以把注册用户加入到其他相关的组中 2、 Group Browser：组管理，管理员可以自己添加相应的组然后进行权限，注册用户配置。 三、 Global Settings 1、 附件设置： Global Settings—>Attachments，点击图中的Edit Configuration进行附件的相关设置。 2、 首页面板设置： Global Settings—>Defalut Dashboard，可以进入系统默认的面板进行设置。 (1) 单击“增加”可以在左侧或右侧面板中增加想要显示的栏目： (2) ⑵选中某个栏目，单击“修改”可以修改其设置； (3) ⑶选中某个栏目，单击“Copy”可以复制一个栏目； (4) ⑷选中某个栏目，单击“删除”可以将面板中的栏目删除； (5) ⑸unselect 是取消对某个栏目的选择。 另外，对于首页面板的设置，也可以通过点击首页右上角的 管理门户页 进行新增面板： 点击“增加”后就建立了一个新的首页显示面板，点击次面板对应操作中的 详细配置 进行 面板内容设置后，点击 返回 dashboard 此面板即可生效。若要恢复系统默认的面板设置， 需要点击首页右上角的 管理门户页，在新的页面中点击 复原缺省，即可恢复。 3、 一般性设置 Global Settings—> General Configuration 进入页面，点击页面底端的 EditConfiguration即可进行设置： 4、 全局性权限 Global Settings—>Global Permissions，这里设置的权限适用于系统内所有的项目，但与某个项目所设定的特殊权限无关，某个项目可以通过 Permission Schemes 设定其特定的权 限。 另外，可以通过下图选择相应的权限并赋予某个组来增加这个组所拥有的权限。 5、 问题链接 Global Settings—> lssue Linking 进入页面后可以点击“Activate”激活此功能，然后 可以新建问题链接类型： 链接类型建立之后显示如下： 此时，在某个问题的详细显示页面就会出现“链接”到其他问题这样的字段，如图： 链接建立后，在此问题页面会显示： 单击图中链接的问题，会跳转到EW-12的问题页面，该页面内同样会有链接问题的显示： 6、 外观与样式： Global Settings—>Look and Feel，设置系统的Logo，Colours以及Date/Time Formats. 7、 邮件服务设置： Global Settings—>Mail Servers，进入邮件服务设置页面，如图： 点击图中的“编辑”可以更改邮件服务器地址、端口以及默认发送邮件地址等信息。点击 Send a Test Email 可以测试邮件服务是否可以正常。 8、 子任务设置： Global Settings—>Sub-Tasks，进入设置页面，如图： 此时，在某个问题的详细显示页面就会出现“创建”子任务这样的字段，如图： 单击图中的“创建子任务”即可新建一个issue。 注：此功能在 bug 管理流程中一般不使用，因为提交 bug 不存在嵌套，应该本着“单个问题 单个提交”的原则。 9、 事件跟踪设置 Global Settings—>Time Tracking，可以设置时间跟踪机制，如图： 点击图中的“Activate”是该功能生效。此时，在新建问题的时候，在页面最下端就会出现如下内容 这样新建问题后，在该问题的页面内就会增加了估算时间这一项，如图： 通过此功能，可以评估工作量。（建议：此项由项目经理填写。） 10、 用户默认设置 Global Settings—>User Defaults ，可以设置用户收到通知邮件的格式（text/html），查询 问题时页面显示的最多问题数以及用户自身发生改变时是否能收到通知邮件，如图： 点击页面中的 Edit default values 进行设置， 设置完成，点击更新，进入新的页面： 11、 工作流 Global Settings—>Workflows，点击Workflows进入到页面，如下图 上面图中已经存在一个默认的jira工作流和一个创建好的develop flows工作流，默认jira工作流是不可以删除的。下面创建一个新的工作流步骤： 注：制作工作流最重要的是根据自己公司的测试规范制定，有的可能比较复杂，有点可能比较简单，适合的才是最好的。 工作流图画出以后，下面就是根据图进行增加工作流了： 1、入工作流name和description，如下图： 2、点击add后，，如下图页面，点击workflows工作流那行的steps链接 3、点击steps链接后，进入下面页面，然后根据 新建打开 打开指派 打开推迟 打开已解决 打开不是问题 推迟指派 指派已解决 已解决重开 上面的状态都是Issue Settings—>Statuses中进行定义状态的。 4、到workflows进行页面设置： 5、 在上图先按照工作流图进行添加完成： 6、 添加完成后，进行状态转变设置，在下图中，点击Add Transition按钮 进入下页面 其他的按照上面进行操作。 7、 Transition view: 这里总共有四个选项 NO VIEW FOR transition 事务触发后不会有任何页面跳出 Default Screen 跳出一个和创建BUG差不多的页面 Resolve Issue Screen 跳出一个解决问题的页面 Workflow Screen 跳出一个问题分配的页面 8、 工作流设置完成后，还要在项目中应用到该工作流才算完成。 新建一个项目：在Projects—>Projects页面中，点击Add Project 填写完成后。 点击图中选择的”select scheme” 选择刚刚创建的scheme，点击Associate按钮，进入第二步骤 在次点击Associate按钮，OK，工作流已经配置到”测试”项目中去了 注：不同版本的JIRA可能有些操作步骤不同，但大致情况是这样一个流程。 四、 Schemes 1、 安全策略： Schemes—>Issue Security Schemes—>Add Issue Security Scheme ，输入具体的安全设置名称(name)及详细描述（description）即可，其中详细描述为可选项。 新增后可点击Security Levels（或安全设置的名称），设置不同的安全级别，如图所示： 单击右侧的增加可以设置处于某个安全级别的人员或组，如图所示： 单击 Default 可以将 jira 默认的安全级别改成当前设置的级别，单击之后可以在安全级别 设置的上方看到 Change default security level to "None" 的字样。 另外此处设置了安全级别要应用到项目中，在新建项目的时候或者建好项目之后可以更改。 2、 权限设置 Schemes—>Permission Schemes(很重要的一步)（在此之前可能需要新建相关的组，比如：开发组，测试组，市场组等，这样方便赋予权限） 点击Add Permission Scheme，新增一权限设置，或直接点击已有的项目权限进行copy，但记得要修改名称。新增后，点击旁边的Permissions进行编辑，具体设置如下： 3、 通知设置 Schemes—>Notification Schemes，单击Add Notification Scheme进行新增权限，也可以直接点击copy复制系统默认的通知设置，然后在里面进行更改。（建议不要更改系统默认的设置），添加完通知设置之后，点击通知设置的名称或点击右侧的Notifications即可进行通知的具体设置。 4、 工作流计划 Schemes—>Workflow Schemes，单击Add workflow scheme 来增加工作流设置以便与项目进行关联，如图： 点击增加即可创建一个工作流的设置，下面需要为这个设置指派一个工作流： 单击图中的assign a workflow，选择问题类型，选择相应的工作流，单击“增加”： 这样就建立了一个新的工作流设置，这样在新建项目的时候就可以通过这个设置将我们自己定义的工作流与项目联系到一起了。 如果想要讲图中的inactive 状态变成active，必须将设置与项目关联起来就可以。 五、 Issue Fields： 1、 自定义字段 Issue Fields—>Custom Fields，自定义页面内显示的字段。 单击页面内的Add Custom Field 可以进行自定义字段的添加，选择图中某一类型的字段。单击“Next”，如图： 在下图中字段名称对应文本框内填写需要添加字段的名称，并给予描述： 在此处选择添加字段所使用的模板： 选择此字段所要应用到的问题类型： 选择将此字段设置作为全局设置或是只针对某个项目： 单击“Finish”完成设置。在如下页面选择字段所显示的页面： 单击“更新”完成设置。设置前后页面比较： 2、 字段设置： Issue Fields—>Field Configurations，可以自己增加，也可以复制原有的进行修改，如图： 新增字段后如下： 注：此设置需与“Field Configuration Schemes”中的策略关联才可以生效。 3、 字段设置策略 Issue Fields—>Field Configuration Schemes，通过此处可以自定义添加或复制原有策略来增加新的策略，从而可以将所设置的字段与项目关联起来，如图： 4、 问题导航栏 Issue Fields—>Navigator Columns，通过此处可以增加或隐藏现有导航栏内的显示内容，也可调整前后顺序，如图： 六、 Issue Settings 1、 Issue Types：问题类型 Issue Settings—> Issue Types，通过配置可以设置出不同的问题类型，默认的问题类型有4种如下图： 在Add New Issue Type下面输入name和描述，就可以添加新的问题类型了，这个可以根据自己的需要进行增加。 2、 Priorities：优先级 Issue Settings—> Priorities，这个是设置问题的优先级，可以更加自己的需要进行修改，删除或添加。如下图是我修改了的优先级，把优先级该为问题的严重程度，方便自己使用，这里可以每个公司进行修改： 3、 Resolutions：操作决策 Issue Settings—> Resolutions，主要是配置开发人员对问题的解决方法状态选择，比如选择这个问题关闭，或者是已经存在，下个版本解决等。这些都是在这里进行配置，如下图，如果你不爽英文的话完全可以全部修改为中文。:-)o(∩_∩)o… 4、 Statuses：问题状态 Issue Settings—> Statuses，可以设置问题的状态，包含问题创建，关闭，重开等，可以根据工作流进行配置，如下图： 右边的workflows是工作流，点击下面链接就可以跳到工作流设置页面。 七、 Import & Export 1、 数据备份为xml文件： Import & Export—>Backuo Data to XML，通过此处可以将数据库中的数据备份成XML文件，这种备份既可以用于使用JIRA自带的数据库，也可以用于连接了外部数据库的数据备份，使用外部数据库的数据备份也可以直接备份该数据库。 单击图中的”Backup”之后会将数据备份，之后会提示填写备份路径，如图： 注：使 用这 种方法 备份 数据库 只是 一次性 备份 ，如果 想要 实现周 期性 备份需 要在 SystemServices 中进行设置。 设置如下：如果在安装 jira 的过程中指定了备份路径的话,jira 的备份服务会自动启动； 如果没有进行设置，可以进入 SystemServices 中，设置其保存路径，文件名格式，文件 保存为 zip 格式或 xml 格式以及备份时间间隔。如图： 2、 从XML文件恢复数据： Import & Export—>Restore Data from XML，通过此处可以将已经备份的数据重新恢复到系统中，与Backuo Data to XML相对应。 数据导入的时间视文件大小而定，导入成功之后显示如下页面，并且需要重新登录系统： 3、 外部导入数据 Import & Export—> External System Import、通过此处可以将外部的数据导入进来： 八、 Options & Settings 1、 Options&Settings—>Send E-mail，管理员可以通过这个功能通知相关用户信息。 九、 System 这个模块都是一些基本配置显示信息，一般安装JIRA都不用在这里面进行配置。可以不去管他。 第四章、 JIRA用户使用 1、登陆与注册 在成功安装配置完成的界面上点击“登陆到JIRA”，就会看到JIRA的登陆界面了； 如果已注册，就输入用户名和密码进入。 没有注册，点击“注册”链接 注册成功后进行登陆。 2、 创建问题 一般用户注册后，要通过管理员对你的权限进行配置。 项目一般又管理员进行创建，设置，这里只写普通帐户的使用。 登陆成功后，进入下面页面 点击“创建问题”链接，进入下面页面，选择项目，问题类型： 选择完，点下一步，然后详细填写问题的情况： 填写完成后，点“创建”。一个问题就创建完成，然后邮件就会发送到相关人员邮箱中。 注：上图中的填写，可能每个公司的配置一样，需要根据具体情况进行设置。 3、 浏览项目 在浏览项目的界面可以看到项目的基本信息资料，模块和版本信息及问题分布情况。 4、 查找问题 在查找问题界面上，您可以在界面左侧进行查询条件的设置，JIRA提供了强大的查询功能，在你设定好查询条件后，还可以将查询条件保存起来，定义为过滤器，供以后的重复使用，也可以将保存的过滤器给团队的其他成员。
vs 搭建团队项目服务器,tfs中如何创建团队项目及如何操作团队项目
创建团队项目集合tfs server管理控制台\团队项目集合页面。选择'创建集合'链接，按向导即可创建项目集合。创建团队项目创建好团队项目集合后，就要开始创建团队项目了。进入vs，连接上tfs服务器后，从下面菜单选择'新建团队项目...'然后，输入团队项目名称，过程模板选择Agile，源代码管理选择tfs，然后直到完成即可创建一个团队项目。删除团队项目为了测试，我们往往会创建一个供测试的团队项目，...
敏捷项目管理-如何从0-1搭建敏捷团队
一、从哪里开始？ 敏捷是一种方法、工具，和其他方法或者工具一样，在其适用范围内可以返回显著的作用。那么有没有比较直观的判断标准来确定是否合适使用敏捷方法来进行项目管理呢？答案是有的！ 1、从做事的对象角度判断 complex部分就是我们实施敏捷项目管理的适用范围。需求和技术都明确的简单问题，可用传统预测方法去处理即可，需求和技术都不明确的混沌问题，由研究院去探索。既不简单又不确定的复杂问题，可以考虑用敏捷方法！ 2、从做事的过程角度判断 通过实验性的过程，快速迭代试错，...
持续集成、持续交付、微服务----代码托管平台Bitbucket-Bitbucket功能说明
Bitbucket简介 Bitbucket 的功能不仅仅是 Git 代码管理。借助 Bitbucket，团队可以集中规划项目、开展代码协作以及进行测试和部署。 免费的无限个私有代码库 5 人以下的小型团队免费使用。可以扩展为 Standard（3 美元/用户/月）或 Premium（6 美元/用户/月）。 一流的 和Jira 、Trello 集成 可以直接从 Jira 事务或 Trello 卡片创建 Bitbucket 分支，确保项目井井有条。 持续交付功能 ...
GIT - 代码分支管理模型之二
书接上文 在前一篇文章GIT 代码分支管理模型之一中，我们一起了解了一种叫做“成功的代码分支管理模型”。在这种模型中，我们确实可以很灵活地应对各种场景下的代码分支管理。 理想总是那么美好，而现实偏偏那么蛋疼！ 要用好这种代码分支管理模型，需要全体开发人员对于GIT有比较深入的了解，比如merge, rebase,而且在每一次GIT的操作的时候要很清楚地知道自己正在开发的功能属于哪个分支的。对于...
2023年北航敏捷软件工程

78

社区成员

92

社区内容

发帖
与我相关
我的任务
社区描述
2023年北航敏捷软件工程，主讲教师罗杰、任健。
软件工程 高校
社区管理员
  • clotho67
  • neumy
  • BrownSearch
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章