Jump to content

Talk:02 Code Review and Approval Procedure: Difference between revisions

From HEIN+FRICKE
← Older editNewer edit →
VisualWikitext
Artha.kadamb@heinfricke.team (talk | contribs)
hf_all_edit, mw_hf_all, mw_mercedes
53 edits
Artha.kadamb@heinfricke.team (talk | contribs)
hf_all_edit, mw_hf_all, mw_mercedes
53 edits
Line 1: Line 1:
== 1. Introduction ==
== 1. Introduction ==


=== 1.1 Purpose: ===
=== 1.1 Purpose ===
* Establish a standardized process for reviewing and approving code changes to maintain quality, catch issues early, and ensure audit traceability using tools like Git.
* Establish a standardized process for reviewing and approving code changes to maintain quality, catch issues early, and ensure audit traceability using tools like Git.


=== 1.2 Scope: ===
=== 1.2 Scope ===
* Covers all code changes in software projects across development teams, focusing on Git-based repositories.
* Covers all code changes in software projects across development teams, focusing on Git-based repositories.


=== 1.3 Objectives: ===
=== 1.3 Objectives ===
* Enforce coding standards, reduce bugs, promote collaboration, and keep detailed records for internal audits.
* Enforce coding standards, reduce bugs, promote collaboration, and keep detailed records for internal audits.


=== 1.4 Key Terms: ===
=== 1.4 Key Terms ===
* Git: Version control system for tracking code changes.
* Git: Version control system for tracking code changes.
* Branching: Creating separate code lines (e.g., feature branches) in Git.
* Branching: Creating separate code lines (e.g., feature branches) in Git.
Line 16: Line 16:
* Reviewer: Assigned team member who evaluates the PR.
* Reviewer: Assigned team member who evaluates the PR.


=== 1.5 Standards: ===
=== 1.5 Standards ===
* Align with company coding guidelines and audit requirements for traceability.
* Align with company coding guidelines and audit requirements for traceability.


=== 1.6 Audience: ===
=== 1.6 Audience ===
* Developers, reviewers, team leads, and auditors.
* Developers, reviewers, team leads, and auditors.


=== 1.7 How to Use: ===
=== 1.7 How to Use ===
* Follow this for all code changes; store in Confluence for access.
* Follow this for all code changes; store in Confluence for access.


== 2. Roles and Responsibilities ==
== 2. Roles and Responsibilities ==


=== 2.1 Key Roles: ===
=== 2.1 Key Roles ===
* Developer: Makes code changes, runs tests, creates PRs.
* Developer: Makes code changes, runs tests, creates PRs.
* Reviewer: Reviews PRs, adds comments, approves or requests changes.
* Reviewer: Reviews PRs, adds comments, approves or requests changes.
* Team Lead: Assigns reviewers, resolves issues, ensures process adherence.
* Team Lead: Assigns reviewers, resolves issues, ensures process adherence.


=== 2.2 Developer Tasks: ===
=== 2.2 Developer Tasks ===
* Use Git for branching and code changes.
* Use Git for branching and code changes.
* Run test cases before creating PRs.
* Run test cases before creating PRs.
* Act on reviewer comments and update PRs.
* Act on reviewer comments and update PRs.


=== 2.3 Reviewer Tasks: ===
=== 2.3 Reviewer Tasks ===
* Review code, add comments on issues.
* Review code, add comments on issues.
* Re-review updates until PR is approved.
* Re-review updates until PR is approved.


=== 2.4 Team Collaboration: ===
=== 2.4 Team Collaboration ===
* Use Slack #code-reviews for notifications.
* Use Slack #code-reviews for notifications.
* Link PRs to Jira tickets for tracking.
* Link PRs to Jira tickets for tracking.
Line 47: Line 47:
== 3. Code Review and Approval Process Overview ==
== 3. Code Review and Approval Process Overview ==


=== Goal: ===
=== 3.1 Goal ===


* Ensure code changes are reviewed thoroughly via Git, with tests run and comments addressed before approval.  
* Ensure code changes are reviewed thoroughly via Git, with tests run and comments addressed before approval.  


=== Core Steps: ===
=== 3.2 Core Steps ===


* Use Git for all version control.  
* Use Git for all version control.  
Line 63: Line 63:
* Merge approved PR.  
* Merge approved PR.  


=== SDLC Fit: ===
=== 3.3 SDLC Fit ===


* Integrate with Agile sprints (review PRs daily) or Waterfall phases; track in Jira.  
* Integrate with Agile sprints (review PRs daily) or Waterfall phases; track in Jira.  


=== Change Tracking: ===
=== 3.4 Change Tracking ===


* Use Git commits linked to Jira (e.g., “Fix JIRA-123”).  
* Use Git commits linked to Jira (e.g., “Fix JIRA-123”).  


=== Process Flow: ===
=== 3.5 Process Flow ===


* Step 1: Developer branches in Git and makes changes.  
* Step 1: Developer branches in Git and makes changes.  
Line 79: Line 79:
* Step 5: Repeat reviews until approval; merge PR.  
* Step 5: Repeat reviews until approval; merge PR.  


=== Exceptions: ===
=== 3.6 Exceptions ===


* Emergency changes allow quick approval with Team Lead sign-off; log in Jira.  
* Emergency changes allow quick approval with Team Lead sign-off; log in Jira.  


=== Version Control: ===
=== 3.7 Version Control ===


* Require Git branches like feature/JIRA-123; protect main.  
* Require Git branches like feature/JIRA-123; protect main.  
Line 91: Line 91:
== 4. Code Review Planning ==
== 4. Code Review Planning ==


=== Review Types: ===
=== 4.1 Review Types ===


* Feature: For new code changes (e.g., new API).  
* Feature: For new code changes (e.g., new API).  
Line 97: Line 97:
* Emergency: For urgent fixes.  
* Emergency: For urgent fixes.  


=== Scheduling: ===
=== 4.2 Scheduling ===


* Plan reviews in daily standups; set 24-hour turnaround.  
* Plan reviews in daily standups; set 24-hour turnaround.  
Line 103: Line 103:
* Notify via Teams when PR is ready.  
* Notify via Teams when PR is ready.  


=== Review Criteria: ===
=== 4.3 Review Criteria ===


* Code changes follow style guides.  
* Code changes follow style guides.  
Line 109: Line 109:
* No security issues.  
* No security issues.  


=== Risk Checks: ===
=== 4.4 Risk Checks ===


* Verify code changes don't break existing features.  
* Verify code changes don't break existing features.  
* Ensure test cases cover edge cases.  
* Ensure test cases cover edge cases.  


=== Mitigation Plans: ===
=== 4.5 Mitigation Plans ===


* Run automated tests before PR.  
* Run automated tests before PR.  
* Use Git rebase for clean history.  
* Use Git rebase for clean history.  


=== Approvals: ===
=== 4.6 Approvals ===


* At least 1 reviewer; 2 for critical changes.  
* At least 1 reviewer; 2 for critical changes.  
* Log in Git PR.  
* Log in Git PR.  


=== Communication: ===
=== 4.7 Communication ===


* Share PR links in Teams.  
* Share PR links in Teams.  
* Update Jira with status.  
* Update Jira with status.  


=== PR Description: ===
=== 4.8 PR Description ===


* Include Jira ID, code changes summary, test results.  
* Include Jira ID, code changes summary, test results.  


=== Dependencies: ===
=== 4.9 Dependencies ===


* Check library versions in Git commits.  
* Check library versions in Git commits.  
Line 139: Line 139:
== 5. Code Review and Approval Execution ==
== 5. Code Review and Approval Execution ==


=== Pre-Review Activities: ===
=== 5.1 Pre-Review Activities ===


* '''Git and Branching''': Use Git; create branches (e.g., git checkout -b feature/JIRA-123).  
* '''Git and Branching''': Use Git; create branches (e.g., git checkout -b feature/JIRA-123).  
Line 149: Line 149:
* '''Checklist''': Confirm tests pass, link Jira, notify on Teams.  
* '''Checklist''': Confirm tests pass, link Jira, notify on Teams.  


=== Review Execution: ===
=== 5.2 Review Execution ===


* '''Assign Reviewer''': Team Lead confirms assignment.  
* '''Assign Reviewer''': Team Lead confirms assignment.  
Line 167: Line 167:
* '''Logging''': Record comments/approvals in Git.  
* '''Logging''': Record comments/approvals in Git.  


=== Post-Review Activities: ===
=== 5.3 Post-Review Activities ===


* '''Approval''': Reviewer approves; merge PR (e.g., squash merge).  
* '''Approval''': Reviewer approves; merge PR (e.g., squash merge).  

Revision as of 11:13, 22 December 2025

1. Introduction

1.1 Purpose

  • Establish a standardized process for reviewing and approving code changes to maintain quality, catch issues early, and ensure audit traceability using tools like Git.

1.2 Scope

  • Covers all code changes in software projects across development teams, focusing on Git-based repositories.

1.3 Objectives

  • Enforce coding standards, reduce bugs, promote collaboration, and keep detailed records for internal audits.

1.4 Key Terms

  • Git: Version control system for tracking code changes.
  • Branching: Creating separate code lines (e.g., feature branches) in Git.
  • Pull Request (PR): Git mechanism for proposing and reviewing code changes.
  • Reviewer: Assigned team member who evaluates the PR.

1.5 Standards

  • Align with company coding guidelines and audit requirements for traceability.

1.6 Audience

  • Developers, reviewers, team leads, and auditors.

1.7 How to Use

  • Follow this for all code changes; store in Confluence for access.

2. Roles and Responsibilities

2.1 Key Roles

  • Developer: Makes code changes, runs tests, creates PRs.
  • Reviewer: Reviews PRs, adds comments, approves or requests changes.
  • Team Lead: Assigns reviewers, resolves issues, ensures process adherence.

2.2 Developer Tasks

  • Use Git for branching and code changes.
  • Run test cases before creating PRs.
  • Act on reviewer comments and update PRs.

2.3 Reviewer Tasks

  • Review code, add comments on issues.
  • Re-review updates until PR is approved.

2.4 Team Collaboration

  • Use Slack #code-reviews for notifications.
  • Link PRs to Jira tickets for tracking.

3. Code Review and Approval Process Overview

3.1 Goal

  • Ensure code changes are reviewed thoroughly via Git, with tests run and comments addressed before approval.

3.2 Core Steps

  • Use Git for all version control.
  • Apply branching strategy for code changes.
  • Make code changes and run test cases.
  • Create Pull Request in Git.
  • Assign reviewer(s).
  • Reviewer reviews and add comments.
  • Comments are acted upon by the developer.
  • Review and repeat until PR approval.
  • Merge approved PR.

3.3 SDLC Fit

  • Integrate with Agile sprints (review PRs daily) or Waterfall phases; track in Jira.

3.4 Change Tracking

  • Use Git commits linked to Jira (e.g., “Fix JIRA-123”).

3.5 Process Flow

  • Step 1: Developer branches in Git and makes changes.
  • Step 2: Run tests locally or in CI.
  • Step 3: Create PR, assign reviewer.
  • Step 4: Reviewer adds comments; developer acts on them.
  • Step 5: Repeat reviews until approval; merge PR.

3.6 Exceptions

  • Emergency changes allow quick approval with Team Lead sign-off; log in Jira.

3.7 Version Control

  • Require Git branches like feature/JIRA-123; protect main.
  • Automation: Use GitHub Actions for auto-tests on PR creation.

4. Code Review Planning

4.1 Review Types

  • Feature: For new code changes (e.g., new API).
  • Bugfix: For minor updates.
  • Emergency: For urgent fixes.

4.2 Scheduling

  • Plan reviews in daily standups; set 24-hour turnaround.
  • Use Git branching to isolate changes.
  • Notify via Teams when PR is ready.

4.3 Review Criteria

  • Code changes follow style guides.
  • Test cases run and pass (e.g., >90% coverage).
  • No security issues.

4.4 Risk Checks

  • Verify code changes don't break existing features.
  • Ensure test cases cover edge cases.

4.5 Mitigation Plans

  • Run automated tests before PR.
  • Use Git rebase for clean history.

4.6 Approvals

  • At least 1 reviewer; 2 for critical changes.
  • Log in Git PR.

4.7 Communication

  • Share PR links in Teams.
  • Update Jira with status.

4.8 PR Description

  • Include Jira ID, code changes summary, test results.

4.9 Dependencies

  • Check library versions in Git commits.

5. Code Review and Approval Execution

5.1 Pre-Review Activities

  • Git and Branching: Use Git; create branches (e.g., git checkout -b feature/JIRA-123).
  • Code Changes: Do code changes
  • Run Test Case: Execute unit/integration tests local
  • Commit Changes: Commit changes (e.g., git commit -m "JIRA-123: Add login")
  • Create Pull Request: Push branch, create PR in GitHub/Bitbucket with description.
  • Assign Reviewer: Select reviewer(s) in PR tool or Jira.
  • Checklist: Confirm tests pass, link Jira, notify on Teams.

5.2 Review Execution

  • Assign Reviewer: Team Lead confirms assignment.
  • Reviewer Reviews and Adds Comments: Evaluate code, add feedback on standards, tests, and issues.
  • Comments Are Acted Upon: Developer updates code, commits, and notifies reviewer.
  • Review and Repeat: Re-review updates until all issues resolved and PR approved.
  • Tools: GitHub/Bitbucket for reviews; SonarQube for quality.
  • Checklist: Verify functionality, style, tests.
  • Feedback: Use “Request Changes” or “Approve” in Git tool.
  • Logging: Record comments/approvals in Git.

5.3 Post-Review Activities

  • Approval: Reviewer approves; merge PR (e.g., squash merge).
  • Verification: Run CI tests post-merge.
  • Notifications: Post merge in Teams; update Jira.
  • Documentation: Update Confluence if needed.

6. Document Control and Versioning

  • Owner: Team Lead; backup Senior Developer.
  • Changelog: v1.0 (2025-09-22): Initial based on user points.
  • Review: Every 6 months.
  • Retention: 3 years in Confluence/AWS S3.
  • Access: Team leads edit; auditors view.
  • Updates: Approve via Team Lead/CTO.

7. Appendices

  • Templates: PR template, review checklist.
  • Glossary: Git, PR, Branching.
  • References: Coding standards policy.
  • Contacts: Team Lead: [Name], [Email], Slack @[handle].
  • Sample Logs: PR approval: “Approved by [Reviewer] at [Date].”
  • Checklists: Pre-review table (Git, tests, PR).
Retrieved from "https://doc.heinfricke.team/index.php?title=Talk:02_Code_Review_and_Approval_Procedure&oldid=967"