SCM with MKS Integrity: Workflow, Tool Comparison, and Practical Governance

Source code management (SCM) with MKS Integrity helps teams that need centralized control, audit trails, and strict change governance. This revised guide explains the SCM model, shows a practical workflow, and maps it against modern alternatives so you can run or modernize legacy environments safely.

Originally published on 2010-03-21; fully revised and updated.

The original post was a SlideShare embed (ID: 1117753) with no written technical walkthrough. This version is an independent, implementation-focused reference based on standard SCM practices and common MKS Integrity usage patterns. Original post: Power Point PPT: Scm With Mks Integrity.

What MKS Integrity means in an SCM program

MKS Integrity (later known in PTC product branding as Integrity / Windchill RV&S) is generally used as a centralized SCM and lifecycle management system. Teams typically rely on it when they need clear traceability from change request to code change to release baseline.

• Centralized repository and controlled check-in/check-out flow.
• Association of source changes with change requests or work items.
• Baselines for repeatable builds and release audits.
• Promotion states or gated progression toward release.

Typical centralized SCM workflow

A robust MKS-style workflow emphasizes approval, traceability, and controlled promotion rather than unrestricted branching. The diagram below shows a common pattern.

flowchart TD
    A[Change request approved] --> B[Create task or work item]
    B --> C[Checkout files to sandbox]
    C --> D[Implement and test changes]
    D --> E[Check in with change ID]
    E --> F[Run CI build and validation]
    F --> G{Quality gates pass}
    G -- no --> C
    G -- yes --> H[Create baseline]
    H --> I[Promote to release stream]

MKS Integrity vs Git and Subversion

Example controls you can implement today

If your organization runs mixed tooling (for example, legacy centralized SCM plus Git for newer services), enforce a shared traceability standard. The examples below are practical and tool-agnostic.

# Branch and commit using a change-request ID convention
git checkout -b feature/CR-1042-session-timeout
git add .
git commit -m "CR-1042: adjust session timeout handling"
git push -u origin feature/CR-1042-session-timeoutCode language: PHP (php)

#!/usr/bin/env bash
set -euo pipefail

LAST_MSG="$(git log -1 --pretty=%B)"
echo "$LAST_MSG" | grep -Eq '^CR-[0-9]+:' || {
  echo "Commit message must start with CR-1234:"
  exit 1
}Code language: PHP (php)

traceability_policy:
  require_change_id: true
  commit_pattern: "^CR-[0-9]+:"
  require_peer_review: true

release_policy:
  require_green_ci: true
  require_approved_work_items: true
  require_baseline_or_tag: trueCode language: JavaScript (javascript)

Common pitfalls

• Weak change-to-code linkage (for example, missing change IDs in commits/check-ins).
• Creating baselines too late, which makes release reconstruction difficult.
• Treating centralized SCM as a file store instead of a governed process.
• Skipping automated validation gates before promotion.
• Running legacy SCM without a documented modernization or support plan.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.