GitHub Task Management Flowchart - Sanjel-Energy-Services/eService_WorkItems GitHub Wiki
GitHub 使用的几点注意事项
- 创建新任务时，注意所创建任务所属的代码仓库，初始分类为Task。
- 只有需要创建分支，才需要创建任务。如果是子任务，需从主任务中创建子任务，自动形成关联。
- 初步分析工作，不需要单独创建子任务，工时直接计入到主任务下。如果主任务需转化为Summary任务，则工时转计入到第一个子任务中，并说明。
- 所有相关测试案例链接需罗列在主任务之下，供开发员理解需求和执行测试之用。
- 每个主任务下可创建一个测试执行子任务，供测试工时记录和测试备注之用
- 测试失败，需在相关任务下创建bug子任务
- 事务性任务，可以建立Misc类型任务，它没有关联的代码仓库
- 模型变动及代码库发布任务在其服务的主任务下建立子任务，并在主任务中回贴通知相关人员
Key Considerations for Using GitHub
- Task Repository Assignment: When creating a new task, ensure it is assigned to the correct code repository. The default category for new tasks is "Task".
代码仓库分配：创建新任务时，确保其归属于正确的代码仓库。新任务的默认分类为 "Task"（任务）。
- Branch-Based Task Creation: Only create a task when a new branch is required. For subtasks, create them under the parent task to automatically establish dependencies.
基于分支的任务创建：仅在需要新建分支时创建任务。子任务需从主任务下创建，以自动建立关联。
- Preliminary Analysis Work: No need to create separate subtasks for initial analysis. Track time directly under the parent task. If the parent task is converted into a "Summary" task, transfer logged time to the first subtask and document the change.
初步分析工作：初步分析无需单独创建子任务，工时直接计入主任务。若主任务转为 "Summary"（汇总任务），则将工时转移至首个子任务并说明变更。
- Test Case Links: List all relevant test case links under the parent task for developers to review requirements and execute tests.
测试案例链接：所有相关测试案例链接需列在主任务下，供开发人员理解需求并执行测试。
- Test Execution Subtask: Create one "Test Execution" subtask per parent task to log testing time and notes.
测试执行子任务：每个主任务下可创建一个 "Test Execution"（测试执行）子任务，用于记录测试工时和备注。
- Bug Subtasks: If a test fails, create a "Bug" subtask under the relevant parent task.
Bug子任务：测试失败时，需在相关主任务下创建 "Bug"（缺陷）子任务。
- Miscellaneous Tasks: Use the "Misc" task type for administrative work unrelated to a code repository.
事务性任务：使用 "Misc"（杂项）类型任务处理与代码仓库无关的事务性工作。
- Model/Codebase Updates: For model changes or codebase releases, create subtasks under the parent task and notify stakeholders by posting a reply in the parent task.
模型/代码库更新：模型变动或代码库发布任务需在主任务下建立子任务，并通过在主任务中回复通知相关人员。
graph TD
A[Create or Assign Task] --> B[Analyze and Evaluate Task]
B --> C{Does the task need to be split?}
C -- Yes --> D[Split Task]
D --> E[Create Subtasks]
E --> F[Create sub-issue or Add existing issue]
F --> G[Fill Subtask Information]
G --> H[Fill in the ticket details: Iteration, Estimate Hours, Remain Hours, Category...]
C -- No --> I[Fill Task Information]
I --> J[Fill in the ticket details: Iteration, Estimate Hours, Remain Hours, Category...]
J --> K{Does the task require hours?}
H --> K{Does the task require hours?}
K -- Yes --> L[Category as Task]
K -- No --> M[Category as Summary]
L --> N[Select Repository Publish Convert to Issue]
M --> N[Select Repository Publish Convert to Issue]
N --> O[Task Analysis Completed]
graph TD
A[On the 1st of each month, create a monthly stand-up meeting ticket e.g., Feb 2025 meetings] --> B[Fill in the ticket details: Iteration, Estimate Hours , Remain Hours, Category as Misc]
B --> C{Attend daily stand-up meetings}
C -- Not attending --> J[No need to log work hours or task details]
J -- Next day --> C{Attend daily stand-up meetings}
C -- Attending --> D[What was completed yesterday?]
C -- Attending --> E[What is planned for today?]
C -- Attending --> F[Any issues or blockers?]
D --> G[Log work hours and discussion details after the stand-up meeting]
E --> G[Log work hours and discussion details after the stand-up meeting]
F --> G[Log work hours and discussion details after the stand-up meeting]
G --> H{End stand-up meeting}
G --> C{Attend daily stand-up meetings}
H --> I[Monthly ticket cleanup]
flowchart TD
A[Create a branch for your task] --> B[Name branch with meaningful name, e.g., '123-fix-for-wrong-header-on-scheduler']
B --> C[Implement changes in your branch]
C --> D[Add task note to 'ReleaseNotes']
D --> E[Create a pull request on GitHub targeting the correct branch]
E --> F[Add reviewers in the top right section]
F --> G[Add task to Development section or write 'closes #<task_num>']
G --> H[PR triggers build and tests automatically]
H --> I{Are tests passing and code reviewed?}
I -->|Yes| J{Is PR from 'release' to 'develop'?}
J -->|Yes| K[Plain Merge to keep history consistent]
J -->|No| L[Squash and Merge if multiple commits]
K --> M[Delete your branch after merging]
L --> M
I -->|No| N{Are there reviewer comments?}
N -->|Yes| O[Fix comments in your branch and push changes]
O --> H
N -->|No| P{Are tests failing?}
P -->|Yes| Q[Fix tests or implementation]
Q --> H
P -->|No| J
M --> R[Merge to develop/release triggers build and deploy to Dev/Pre-UAT]
R --> S[Additional actions needed for Test/UAT deployment]
flowchart TD
A[创建任务分支] --> B[为分支命名，例如 '123-fix-for-wrong-header-on-scheduler']
B --> C[在分支中实现更改]
C --> D[在 'ReleaseNotes' 中添加任务备注]
D --> E[在 GitHub 上创建 Pull Request PR，目标分支根据任务目的选择]
E --> F[在 PR 右上角添加评审人]
F --> G[在 Development 部分添加任务或写 'closes #<任务编号>']
G --> H[PR 自动触发构建和测试]
H --> I{测试通过且代码评审完成了吗？}
I -->|是| J{PR 是从 'release' 合并到 'develop' 吗？}
J -->|是| K[使用 Plain Merge 保持历史一致性]
J -->|否| L[如果有多个提交，使用 Squash and Merge]
K --> M[合并后删除分支]
L --> M
I -->|否| N{有评审人评论需要修复吗？}
N -->|是| O[在分支中修复评论并推送更改]
O --> H
N -->|否| P{测试失败了吗？}
P -->|是| Q[修复测试或调整实现]
Q --> H
P -->|否| J
M --> R[合并到 develop/release 分支会触发构建并部署到 Dev/Pre-UAT 环境]
R --> S[部署到 Test/UAT 环境需要额外操作]
flowchart TD
A[Deploy to Pre-UAT] --> B[Team validation of Pre-UAT]
B --> C{Is Pre-UAT validated?}
C -->|Yes| D[Deploy to UAT via GitHub Action]
C -->|No| Z[Fix issues and re-deploy to Pre-UAT]
D --> E[Inform Sanjel Team that UAT has been updated]
E --> F[Send email with version number]
F --> G[Update ReleaseData.cs and pipeline version variables for next release]
G --> H[Get current release build number and date from GitHub]
H --> I[Update Components/ReleaseNotes]
I --> J[Copy current release and paste below itself]
J --> K[Update Version and Date]
K --> L[Remove Items from topmost Release]
L --> M{Is UAT validated?}
M -->|Yes| N[Deploy to Staging via GitHub Action]
M -->|No| Z
N --> O[Create tag off of release e.g., 1.1.0]
O --> P[Inform Sanjel Team that Staging is ready for smoke testing]
P --> Q{Is smoke testing done?}
Q -->|Yes| R[Arrange 5-minute outage for production deployment]
Q -->|No| Z
R --> S[Deploy to Production via GitHub Action]
S --> T[Inform Sanjel Team that deployment to Production is complete]
T --> U[Merge release branch into main]
U --> V[Create release in GitHub and associate with git tag]
V --> W[Copy action artifact to release]
W --> X[Merge main into release]
X --> Y[Merge release into develop]
flowchart TD
A[部署到 Pre-UAT] --> B[团队验证 Pre-UAT]
B --> C{Pre-UAT 是否通过验证？}
C -->|是| D[通过 GitHub Action 部署到 UAT]
C -->|否| Z[修复问题并重新部署到 Pre-UAT]
D --> E[通知 Sanjel 团队 UAT 已更新]
E --> F[发送包含版本号的邮件]
F --> G[更新 ReleaseData.cs 和流水线版本变量]
G --> H[从 GitHub 获取当前 Release 构建号和日期]
H --> I[更新 Components/ReleaseNotes/ReleaseData.cs]
I --> J[复制当前 Release 并粘贴到下方]
J --> K[更新版本号和日期]
K --> L[移除顶部 Release 的内容]
L --> M{UAT 是否通过验证？}
M -->|是| N[通过 GitHub Action 部署到 Staging]
M -->|否| Z
N --> O[从 Release 分支创建标签 例如 1.1.0]
O --> P[通知 Sanjel 团队 Staging 已准备好进行冒烟测试]
P --> Q{冒烟测试是否完成？}
Q -->|是| R[安排 5 分钟停机时间以部署到生产环境]
Q -->|否| Z
R --> S[通过 GitHub Action 部署到生产环境]
S --> T[通知 Sanjel 团队生产环境部署已完成]
T --> U[将 Release 分支合并到 main]
U --> V[在 GitHub 中创建 Release 并关联 Git 标签]
V --> W[将构建产物复制到 Release]
W --> X[将 main 合并到 release]
X --> Y[将 release 合并到 develop]