コンテンツにスキップ

Change Management Procedure

Field Value
Document Owner Takayuki KIKUCHI (Representative Director & CEO)
Effective Date 2026-05-13
Version 1.0
Related Policy Secure Development Policy
Repository in Scope RenderingConsulting/VMS (AuditnQ internal repository)

1. Purpose & Scope

This procedure establishes the operational rules for managing changes to AuditnQ (internally referred to as VMS) throughout the planning, implementation, review, testing, approval, deployment, and recording phases. It is the operational companion document to the Rendering Consulting Inc. Secure Development Policy.

The following types of changes are within scope:

  • Application code changes
  • API / backend logic changes
  • Frontend UI changes
  • Prisma schema, migrations, and data model changes
  • GitHub Actions / Azure Static Web Apps CI/CD configuration changes
  • Test code, QA documentation, and E2E test asset changes
  • Authentication, authorization, and external integration configuration changes

The target system is the AuditnQ application maintained in the GitHub repository RenderingConsulting/VMS.

2. Roles & Responsibilities

CEO (Takayuki KIKUCHI)

The CEO holds final approval authority for material changes, production deployments, emergency changes, and exception handling.

Primary responsibilities:

  • Approving changes to be deployed to the production environment
  • Determining priority for changes with significant business impact
  • Authorizing emergency change execution
  • Approving exception handling
  • Reviewing change history and approval records as required for audit purposes

Approval Process

Pull Requests that result in deployment to the production environment (main branch) require the CEO's explicit "Approve" action on GitHub. The CEO performs approval according to the following process:

  1. Receive release request through Slack or other communication channel
  2. Conduct testing against the PR's Preview environment (Azure Static Web Apps Preview URL)
  3. Confirm test results are as expected
  4. Issue "Approve" on the production-bound PR via GitHub

Pull Requests without the CEO's Approve cannot be merged into the main branch. Approval records are retained in the GitHub PR review history.

External Engineers

External engineers are responsible for the design, implementation, testing, PR creation, and review response for changes.

Primary responsibilities:

  • Understanding change requirements based on Issues / tickets
  • Branch creation, implementation, and commits
  • Compliance with coding standards
  • Execution of required unit tests, E2E tests, and manual verification
  • Pull Request creation
  • Response to review feedback
  • Support for post-deployment verification
  • Maintaining change history in GitHub

3. Change Classification

Changes are classified into two categories. CEO Approve on GitHub is mandatory for all changes deployed to the production environment (main branch), regardless of classification.

Normal Change

Planned, routine changes implemented through the standard process.

Examples:

  • New feature additions
  • Improvements to existing features
  • UI modifications
  • Bug fixes
  • Test additions
  • Documentation updates
  • Wording corrections and minor configuration changes

Normal changes originate from a GitHub Issue, are developed in a working branch, undergo Pull Request review and CEO approval, and are merged to the main branch.

Emergency Change

Changes that require an expedited process due to production incidents, critical security issues, or defects that disrupt business operations.

Examples:

  • Critical production incidents
  • Authentication / authorization defects
  • Data integrity corrections
  • Emergency response to security vulnerabilities

Emergency changes are implemented in hotfix branches. Review and testing are conducted to the extent possible given the urgency. CEO Approve cannot be skipped for emergency changes. Detailed procedures are defined in §13 Emergency Change Process.

4. Branch Strategy

CI/CD workflows are defined via GitHub Actions for the main and staging branches.

main

The branch corresponding to the production environment. Pushes or Pull Requests to main trigger the Main CI/CD pipeline, which builds and deploys to Azure Static Web Apps. Merges to the main branch require the CEO's approval as defined in §10.

Pre-production testing by the CEO is performed against the Preview environment of the Pull Request (Preview URL generated by the Azure Static Web Apps Pull Request build).

staging

The branch corresponding to the verification environment. Pushes or Pull Requests to staging trigger the Staging CI/CD pipeline.

Working Branches

Work for Normal Changes and Emergency Changes is performed on working branches separate from main / staging, and integrated into main / staging through Pull Requests. Working branch naming is not strictly enforced; any name that allows the work content to be identified is acceptable.

5. Change Initiation

Changes are initiated using GitHub Issues as the official source of change requests. Even when requests are received via Slack, verbal communication, email, or other channels, a corresponding GitHub Issue must be created before work begins, and the request content must be consolidated in the Issue.

The Issue must clarify the following:

  • Background / reason
  • Target feature
  • Scope of impact
  • Expected result
  • Desired release timing (if any)
  • Urgency

For bug reports, reproduction steps, screenshots, error messages, and related logs are added as needed.

All Pull Requests must reference the corresponding GitHub Issue using Closes #<issue-number> or Refs #<issue-number> to clearly link the change to its originating request.

6. Development Standards

Development follows the existing coding guides.

Reference documents:

  • doc/coding_guide/frontend/README.md
  • doc/coding_guide/backend/README.md
  • README.md

Key standards include:

  • Use TypeScript
  • Use React functional components
  • Use react-hook-form for form management
  • Use zod for validation
  • Use Zustand for state management as needed
  • Follow the tRPC router / usecase / domain structure for APIs
  • Do not write business logic directly in routers; separate into usecase / domain
  • Do not manually edit Prisma migration files
  • Do not hardcode confidential information
  • Comply with ESLint / Prettier

Commit messages follow the format below, consistent with the PR Agent configuration:

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

Examples of type:

feat | fix | docs | style | refactor | test | chore

Examples:

fix(auth): handle expired session
docs(qa): add e2e checklist

7. Pull Request Process

Changes are reviewed and approved through Pull Requests.

PRs must include the following information:

  • Change summary
  • Change reason
  • Scope of impact
  • Test content
  • Related Issue / ticket
  • Screenshots or verification results (for UI changes)
  • Deployment considerations

The repository includes .github/pull_request_template.md, which defines PR-Agent commands. Examples of available commands:

  • /ask
  • /describe
  • /review
  • /improve --extended
  • /test
  • /update_changelog

PR Agent is configured to automatically provide descriptions, reviews, and improvement suggestions when PRs are created or updated.

8. Code Review

Code reviews verify the following:

  • The implementation is appropriate for the stated change purpose
  • The scope of impact is accurately captured
  • Authentication / authorization is correctly handled
  • Input validation is appropriate
  • No confidential information is included
  • TypeScript type safety is preserved
  • The implementation aligns with existing architecture
  • Separation of router / usecase / domain responsibilities is maintained
  • UI changes are consistent with existing design and usability
  • No performance issues are introduced
  • Test coverage is sufficient
  • Post-deployment verification methods are clear

PR Agent is configured to focus on security, performance, code quality, React-specific improvements, and test addition suggestions during review.

9. Testing Requirements

Tests are conducted according to the nature of the change.

Unit Tests

When changes affect business logic, utilities, or important branching logic, unit tests are added or updated.

Example command:

npm test

Type Checking

For API / backend changes, TypeScript type checking is performed.

npm run typecheck

Lint

For frontend changes, lint is performed.

npm run lint

Or for error-only verification:

npm run lint:errors

Build

For changes targeting deployment, build verification is performed.

npm run build

E2E Tests

For changes affecting major business flows, Playwright E2E tests or equivalent manual verification is performed.

Reference documents:

  • doc/qa/e2e/README.md
  • doc/qa/e2e/run-checklist.md
  • doc/qa/test-scenario-list.md
  • __test__/README.md

Examples of E2E test scope:

  • New project creation
  • Vendor response registration
  • Periodic audit creation
  • Audit target project registration
  • Response file upload / download
  • Authentication and authorization verification

Preview URL Verification (Mandatory for Production Changes)

For Pull Requests targeting the main branch, the CEO performs pre-production verification against the Preview URL generated by the Azure Static Web Apps Pull Request build.

The verification procedure is as follows:

  1. CEO accesses the PR's Preview URL
  2. CEO executes E2E tests relevant to the PR
  3. CEO records the E2E test results as a comment on the PR
  4. CEO confirms that no unexplained regression (unintended impact on existing functionality) has occurred
  5. Upon confirmation, the CEO Approves the PR

The E2E test results and Approve action are retained as audit evidence in the GitHub PR.

10. Approval & Merge

Changes deployed to the production environment require CEO approval before being merged into the main branch.

Branch Protection (via GitHub Repository Rulesets)

The main branch is controlled by the GitHub Repository Ruleset "Auto Review" with the following settings:

Setting Value
Pull Request required Required
Required approving review count 1 or more
Bypass actors None (no administrator or CEO bypass permitted)

Note on Branch Protection Rules vs. Rulesets: The above controls are implemented via GitHub Repository Rulesets rather than the legacy Branch Protection Rules. Functionally equivalent controls (PR required, approval count, no bypass) are enforced. When responding to auditors who ask specifically about "Branch Protection Rules," the accurate response is: "Branch Protection Rules are not configured directly; equivalent controls (PR required, ≥1 approval, no bypass) are enforced via GitHub Repository Rulesets."

Merge Conditions

All of the following conditions must be satisfied before a change can be merged to the main branch:

  • A Pull Request has been created
  • Change content and scope of impact are documented in the PR body
  • A corresponding GitHub Issue is linked
  • Required reviews are complete (at least 1 Approve)
  • Required testing is complete (unit / type check / lint / build / E2E as applicable)
  • CI/CD has succeeded
  • The CEO has issued "Approve" on the PR via GitHub for the production deployment

Independence of Approval

The PR author (external engineer) and approver (CEO) are different individuals, ensuring segregation of duties. The Ruleset's bypass actors are empty; the CEO cannot merge without going through the approval process.

11. Deployment Process

Deployment to Azure Static Web Apps is defined via GitHub Actions.

Staging

Pushes or Pull Requests to the staging branch trigger the Staging CI/CD pipeline.

Main steps:

  1. checkout
  2. Node.js 22.x setup
  3. npm install
  4. npm run prisma:bundle
  5. npm run build:api:staging
  6. cd api && npm run prepare:deploy
  7. Upload to Azure Static Web Apps

Production

Pushes or Pull Requests to the main branch trigger the Main CI/CD pipeline.

Main steps:

  1. checkout
  2. Node.js 22.x setup
  3. npm install
  4. npm run prisma:bundle
  5. npm run build:api:release
  6. cd api && npm run prepare:deploy
  7. Upload to Azure Static Web Apps

Documentation-only changes and certain workflow changes are excluded from deployment via paths-ignore.

12. Post-Deployment Verification

After deployment to production, the CEO performs the following verification.

Functional Verification

The CEO accesses the production environment and confirms:

  • The application is accessible
  • Login functions correctly
  • The target feature operates as expected
  • No errors occur on major screens
  • No API errors are occurring
  • External integrations are unaffected
  • No critical console errors are present
  • E2E or manual tests are re-executed as needed

Continuous Monitoring (Automated)

The production environment is continuously monitored by the following tooling:

Target Tool Description
Uptime monitoring Instatus Continuous monitoring of the production service availability
Activity log Azure Static Web Apps (visible in Azure Portal) Records of operations and events on the resource
Activity log alerts Azure Activity Log Alert Rules Alerts triggered on significant events

Response to Detected Anomalies

When an anomaly is detected by monitoring or alerts, the CEO responds in accordance with the incident response process. As needed, §13 Emergency Change Process and §14 Rollback Procedure are invoked.

13. Emergency Change Process

Emergency changes are implemented in response to production incidents, critical security issues, or defects that impede business continuity. CEO Approve as defined in §10 cannot be skipped for emergency changes, even when expedited. The scope of review and testing may be adjusted based on urgency, but the approval process itself is maintained.

Procedure

  1. Confirm the incident or emergency event
  2. Assess scope of impact and urgency
  3. Notify the CEO of the emergency change and obtain authorization to prioritize the work
  4. Create a hotfix working branch
  5. Implement the minimum necessary fix
  6. Conduct review and testing to the extent appropriate for the urgency
  7. Create a Pull Request and document the change, incident details, and scope of impact in the PR body
  8. CEO performs verification on the Preview URL (scope adjustable based on urgency)
  9. Obtain CEO Approve, merge to main, and deploy to production
  10. Conduct post-deployment verification
  11. Record the post-incident details in the PR body or comments

Post-Incident Recording

The following information must be recorded in the PR body or comments for any emergency change:

  • Incident date and time
  • Incident description
  • Scope of impact
  • Root cause
  • Implemented fix
  • Approver (CEO)
  • Deployment date and time
  • Post-deployment verification results
  • Preventive measures

The GitHub PR Approve record, PR body / comments, and commit history serve as the audit trail.

14. Rollback Procedure

If a critical issue arises after deployment to production, or if a change produces unintended defects, the CEO will determine whether to execute a rollback.

Rollback Method

Rollbacks are executed by creating a Pull Request that uses git revert to undo the problematic change, then merging it to the main branch through the standard change management process. This triggers automatic redeployment of the production environment via the Main CI/CD pipeline.

Force pushes to historical commits and history rewriting are not permitted, as they would compromise the audit trail.

Procedure

  1. CEO confirms the incident state and scope of impact, and decides to execute the rollback
  2. Identify the problematic change (PR or commit)
  3. Create a working branch with git revert applied to the target change
  4. Create a Pull Request for the revert
  5. Record the rollback reason, target change, and execution timing in the PR body
  6. Obtain CEO Approve (same process as §10)
  7. Merge to main, automatically redeploying and reverting production
  8. Perform post-deployment verification
  9. Record post-incident details in the PR body or comments

Post-Incident Recording

The following information must be recorded in the rollback PR body or comments:

  • Rollback reason (incident summary)
  • Target change (original PR number or commit hash)
  • Execution date and time
  • Executor
  • Approver (CEO)
  • Post-rollback verification results
  • Root cause (if identified)
  • Preventive measures

Supplemental

The CEO may consult the Activity Log and deployment history of Azure Static Web Apps in the Azure Portal as needed to confirm the state before and after rollback.

15. Documentation & Audit Trail

The audit trail for change management is maintained primarily through records on GitHub.

Recorded items include:

  • Issues / tickets
  • Pull Requests
  • Commit history
  • Review comments
  • PR Agent review results
  • GitHub Actions workflow execution history
  • Deployment logs
  • Test results
  • Screenshots and verification evidence
  • QA-related documents

During an audit, the following should be traceable for any given change:

  • Who requested the change
  • Who implemented the change
  • What was changed
  • Why it was changed
  • Who reviewed the change
  • Who approved the change
  • When it was deployed to production
  • What tests were executed
  • Whether any issues occurred after deployment

16. Exceptions

Events that deviate from the standard change management process are treated as exceptions.

Prevention of Exceptions

In this repository, direct commits to the main branch and merging without review are physically blocked by GitHub Repository Rulesets (no bypass actors; see §10). Under normal operation, deviation from this procedure cannot occur.

No Pre-Approval Process

For the reasons above, no pre-approval exception request form or workflow is maintained.

Response to Exception Occurrence

If, in the unlikely event, a deviation from this procedure occurs (operational error, temporary Ruleset modification, etc.), the CEO will perform the following after the fact:

  1. Confirm the event and assess the scope of impact
  2. Record the exception in the relevant GitHub Issue or PR
  3. Consider and implement preventive measures

Post-Incident Recording

Post-incident records include:

  • Date and time of exception occurrence
  • Description of deviation from the standard process
  • Scope of impact
  • Reason for the deviation
  • Response taken
  • Approver (CEO)
  • Preventive measures

Audit Trail

Post-incident records are retained in the relevant GitHub Issue or PR and are available for audit review.

17. Version History

Version Date Description Author Approver
1.0 2026-05-13 Initial version Takayuki KIKUCHI Takayuki KIKUCHI