AgentSkillsCN

Release Management

发布管理

SKILL.md
--- frontmatter
skill_id: CICD-RELEASE
version: 1.0.0
last_updated: 2026-01-04
applies_to: [Class A, Class B, Class C]
jurisdiction: [FDA, EU MDR, Global]
prerequisites: [REG-IEC62304, REG-ISO14971, SEC-SECURE-OTA]

Release Management

Purpose

Define controlled release process for medical device software: versioning, branching, verification, approvals, documentation, and post-release monitoring.

When to Apply

  • •Preparing any software release or field update.

Requirements (testable)

  1. •Versioning: Use semantic and/or regulated versioning; tie to configuration baselines; record in release notes. Rationale: traceability.
  2. •Branch Strategy: Maintain protected release branches; gate merges with tests/approvals; tag releases. Rationale: control and reproducibility.
  3. •Verification: Ensure required tests (unit/integration/HIL), coverage, SAST/DAST, and security scans pass for the release build. Rationale: assurance.
  4. •Approvals: Obtain required QA/RA and security approvals; document sign-offs. Rationale: governance.
  5. •Artifacts: Store signed binaries, SBOM, test reports, coverage, and trace matrices; include checksums. Rationale: auditability and integrity.
  6. •Post-Release: Monitor field metrics, incidents, and vulnerabilities; feed into PMS/risk files; patch policy defined. Rationale: lifecycle safety.

Recommended Practices

  • •Maintain a release checklist template.
  • •Generate human-readable and machine-readable release manifests.
  • •Align release cadence with regulatory submission plans when applicable.
  • •Include rollback plan for field updates.

Patterns

Release manifest (YAML):

yaml
version: 1.3.0
git_tag: v1.3.0
artifacts:
  - fw.bin
  - fw.bin.sig
  - sbom.json
checksums:
  fw.bin: sha256:...
approvals:
  qa: alice
  ra: bob
tests: [unit.xml, integ.xml, hil.xml]

Release checklist (excerpt):

code
- [ ] Tests/coverage meet thresholds
- [ ] SAST/DAST clean or issues accepted with rationale
- [ ] SBOM generated and stored
- [ ] Approvals recorded
- [ ] Rollback plan documented

Anti-Patterns (risks)

  • •Ad-hoc releases without baselines/tags -> risk: irreproducible builds.
  • •Missing approvals -> risk: compliance gap.
  • •Shipping without security/verification checks -> risk: defects in field.
  • •No rollback plan -> risk: prolonged outage/safety impact.

Verification Checklist

  • • Version/tag assigned; branch protected; reproducible build recorded.
  • • Required verification passed; SAST/DAST/coverage within thresholds.
  • • Approvals captured (QA/RA/security).
  • • Artifacts signed, checksummed, SBOM and trace matrices stored.
  • • Post-release monitoring plan in place; rollback plan defined.

Traceability

  • •Link release tag to build metadata, change requests, test reports, SBOM, and approvals; store manifest with artifacts.

References

  • •IEC 62304 config/release expectations.
  • •FDA/MDR submission documentation for software versions.
  • •SLSA concepts for provenance (informative).

Changelog

  • •1.0.0 (2026-01-04): Initial release management skill with branching, verification, approvals, and monitoring.

Audit History

  • •2026-01-04: Audit performed. Verified:
    • •IEC 62304 config/release expectations correctly referenced
    • •FDA/MDR submission documentation requirements appropriately noted
    • •SLSA concepts correctly marked as informative