@oddessentials/repo-standards 1.0.1

package/dist/config/standards.python.azure-devops.json

@@ -0,0 +1,557 @@
+{
+  "checklist": {
+    "core": [
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "quality"
+          }
+        },
+        "description": "Maintain proper .gitignore and .dockerignore files to prevent committing secrets, build artifacts, or unnecessary files.",
+        "id": "gitignore-and-dockerignore",
+        "label": "Git and Docker Ignore Files",
+        "stack": {
+          "exampleConfigFiles": [
+            ".gitignore",
+            ".dockerignore"
+          ],
+          "notes": "Use the official github/gitignore Python template. Include **pycache**, .venv/, .pytest_cache, .env, and similar local-only files. .dockerignore must exclude .git, virtual environments, and caches.",
+          "optionalFiles": [
+            ".dockerignore"
+          ],
+          "requiredFiles": [
+            ".gitignore"
+          ],
+          "verification": ".gitignore must exist; .dockerignore is recommended when containerizing or using Docker workflows."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "quality"
+          }
+        },
+        "description": "Run static code linting to enforce consistency and catch common issues early.",
+        "id": "linting",
+        "label": "Linting",
+        "stack": {
+          "exampleConfigFiles": [
+            "pyproject.toml",
+            ".flake8"
+          ],
+          "exampleTools": [
+            "ruff",
+            "flake8"
+          ],
+          "notes": "Configure a primary linter (such as ruff) and keep rules focused on catching real issues without overwhelming developers.",
+          "optionalFiles": [
+            "ruff.toml",
+            ".flake8"
+          ],
+          "requiredFiles": [
+            "pyproject.toml"
+          ],
+          "requiredScripts": [
+            "lint"
+          ],
+          "verification": "pyproject.toml (or ruff.toml / .flake8) signals that linting tools are configured for the repository."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "test"
+          }
+        },
+        "description": "Provide a deterministic unit test framework with a single command to run all tests.",
+        "id": "unit-test-runner",
+        "label": "Unit Test Runner",
+        "stack": {
+          "exampleConfigFiles": [
+            "pytest.ini",
+            "pyproject.toml"
+          ],
+          "exampleTools": [
+            "pytest"
+          ],
+          "notes": "Organize unit tests under a tests/ directory and avoid real network or database calls in this layer.",
+          "optionalFiles": [
+            "pytest.ini",
+            "pyproject.toml",
+            "tests/"
+          ],
+          "requiredScripts": [
+            "test"
+          ],
+          "verification": "Test framework configuration is present; tests/ directory or pytest configuration exists."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "build"
+          }
+        },
+        "description": "Provide a Dockerfile and, if applicable, a docker-compose file for local dev and CI parity.",
+        "id": "containerization",
+        "label": "Containerization (Docker / Docker Compose)",
+        "stack": {
+          "exampleConfigFiles": [
+            "Dockerfile",
+            "docker-compose.yml"
+          ],
+          "exampleTools": [],
+          "notes": "Choose a slim Python base image, pin the version, and clearly document how to start the service in a container.",
+          "optionalFiles": [
+            "docker-compose.yml"
+          ],
+          "requiredFiles": [
+            "Dockerfile"
+          ],
+          "verification": "Dockerfile must be present; docker-compose.yml is optional and indicates orchestration usage."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "release"
+          }
+        },
+        "description": "Use MAJOR.MINOR.PATCH versioning with clear rules and automated changelog generation based on commit history.",
+        "id": "semantic-versioning",
+        "label": "Semantic Versioning",
+        "stack": {
+          "exampleConfigFiles": [
+            "pyproject.toml",
+            "setup.cfg",
+            "CHANGELOG.md"
+          ],
+          "exampleTools": [
+            "bumpversion",
+            "setuptools_scm",
+            "towncrier"
+          ],
+          "notes": "Automate version bumping and changelog generation using setuptools_scm (git-tag based) or bumpversion with towncrier for changelog fragments. Configure CI to automatically update version in pyproject.toml, generate/update CHANGELOG.md from commit messages or changelog fragments, and create git tags. Maintain a single source of truth for versioning.",
+          "verification": "Check that the package version in pyproject or setup configuration follows SemVer and verify that the configured tool (for example, setuptools_scm or bumpversion) automatically computes or bumps the version and generates changelog entries from commit history or fragments."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "quality"
+          }
+        },
+        "description": "Enforce structured commit messages such as Conventional Commits.",
+        "id": "commit-linting",
+        "label": "Commit Linting",
+        "stack": {
+          "exampleConfigFiles": [
+            ".cz.toml",
+            "pyproject.toml"
+          ],
+          "exampleTools": [
+            "commitizen"
+          ],
+          "notes": "Standardize commit messages using commitizen or a similar helper and document the required types and scopes.",
+          "verification": "Use the configured commit helper (for example, commitizen) or hooks to create a test commit and confirm that non-conforming messages are rejected while valid ones are accepted."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "test"
+          }
+        },
+        "description": "Generate readable unit test and coverage reports and enforce a minimum coverage threshold (around 80%) for new or changed code.",
+        "id": "unit-test-reporter",
+        "label": "Unit Test Reporter / Coverage",
+        "stack": {
+          "exampleConfigFiles": [
+            "pytest.ini",
+            "pyproject.toml"
+          ],
+          "exampleTools": [
+            "pytest",
+            "pytest-cov",
+            "coverage.py"
+          ],
+          "notes": "Configure coverage reporting for your test suite and surface summary metrics in CI.",
+          "verification": "Run the unit tests with coverage (for example, pytest with pytest-cov) and confirm that coverage reports are generated and referenced in CI to enforce or track thresholds."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "ci"
+          }
+        },
+        "description": "Single CI pipeline that runs linting, formatting, type checking, tests, coverage, build, and containerization.",
+        "id": "ci-quality-gates",
+        "label": "CI Quality Gates",
+        "stack": {
+          "exampleConfigFiles": [
+            ".github/workflows/*",
+            "azure-pipelines.yml"
+          ],
+          "exampleTools": [],
+          "notes": "Ensure CI runs linting, type checking (if used), tests, and packaging or container checks for Python services before merging.",
+          "verification": "Open the CI configuration and verify there is a job or stage that runs linting, type checking (if used), tests, and any packaging or container checks before merging to main."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "quality"
+          }
+        },
+        "description": "Automatic code formatting to maintain a consistent style across all contributors.",
+        "id": "code-formatter",
+        "label": "Code Formatter",
+        "stack": {
+          "exampleConfigFiles": [
+            "pyproject.toml"
+          ],
+          "exampleTools": [
+            "black"
+          ],
+          "notes": "Use black (or an equivalent opinionated formatter) and treat its output as the single source of truth for code style.",
+          "verification": "Run the configured formatter (for example, `black .` or `black --check .`) and confirm it reports clean formatting on committed code and auto-fixes as expected locally."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "quality"
+          }
+        },
+        "description": "Use git hooks to run linting, formatting, tests, and commit linting before changes are committed.",
+        "id": "pre-commit-hooks",
+        "label": "Pre-Commit Hooks",
+        "stack": {
+          "exampleConfigFiles": [
+            ".pre-commit-config.yaml"
+          ],
+          "exampleTools": [
+            "pre-commit"
+          ],
+          "notes": "Use pre-commit to run ruff, black, and optionally mypy on staged files before committing.",
+          "verification": "Inspect .pre-commit-config.yaml and confirm that hooks for linting, formatting, and optionally type checking are enabled and run on changed files before commits."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "quality"
+          }
+        },
+        "description": "Use static type checking to catch errors before runtime and enforce strictness on new code.",
+        "id": "type-checking",
+        "label": "Type Checking",
+        "stack": {
+          "exampleConfigFiles": [
+            "mypy.ini",
+            "pyproject.toml"
+          ],
+          "exampleTools": [
+            "mypy"
+          ],
+          "notes": "Adopt gradual typing with type hints and mypy, focusing first on critical modules and new code paths.",
+          "optionalFiles": [
+            "mypy.ini"
+          ],
+          "requiredFiles": [
+            "pyproject.toml"
+          ],
+          "requiredScripts": [
+            "typecheck"
+          ],
+          "verification": "pyproject.toml (or mypy.ini) signals that mypy configuration is available for the repository."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "quality"
+          }
+        },
+        "description": "Lock dependencies and scan regularly for known vulnerabilities; fail CI on newly introduced high-severity issues.",
+        "id": "dependency-security",
+        "label": "Dependency Management & Vulnerability Scanning",
+        "stack": {
+          "exampleConfigFiles": [
+            "requirements.txt",
+            "Pipfile.lock",
+            "poetry.lock"
+          ],
+          "exampleTools": [
+            "pip-audit",
+            "safety"
+          ],
+          "notes": "Pin dependency versions and routinely scan for vulnerabilities, prioritizing fixes for critical and high-severity issues.",
+          "optionalFiles": [
+            "requirements.txt",
+            "Pipfile.lock",
+            "poetry.lock"
+          ],
+          "verification": "Dependency lockfile is present; security scanning is configured in CI or project tooling."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "quality"
+          }
+        },
+        "description": "Specify required runtime/engine versions in package manifests to ensure environment stability and prevent version-related issues across development teams.",
+        "id": "runtime-version",
+        "label": "Runtime Version Specification",
+        "stack": {
+          "exampleConfigFiles": [
+            "pyproject.toml",
+            "setup.py",
+            ".python-version"
+          ],
+          "exampleTools": [],
+          "notes": "Specify python_requires in pyproject.toml (e.g., requires-python = \">=3.9\") or setup.py (e.g., python_requires='>=3.9'). Consider adding .python-version for pyenv users to automatically switch to the correct Python version.",
+          "optionalFiles": [
+            ".python-version"
+          ],
+          "requiredFiles": [
+            "pyproject.toml"
+          ],
+          "verification": "pyproject.toml or setup.py must specify python_requires; .python-version is recommended for local development."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "docs"
+          }
+        },
+        "description": "Maintain a comprehensive README and, where applicable, auto-generated API docs to support onboarding and maintainability.",
+        "id": "documentation",
+        "label": "Documentation Standards",
+        "stack": {
+          "exampleConfigFiles": [
+            "README.md",
+            "docs/"
+          ],
+          "exampleTools": [
+            "Sphinx",
+            "MkDocs"
+          ],
+          "notes": "Ensure README explains environment setup and core commands, and generate API docs from docstrings where appropriate.",
+          "optionalFiles": [
+            "docs/",
+            "mkdocs.yml"
+          ],
+          "requiredFiles": [
+            "README.md"
+          ],
+          "verification": "README.md is present in the repository root; docs/ directory or documentation tooling configuration exists if applicable."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "governance"
+          }
+        },
+        "description": "Include standard governance files (LICENSE, CODE_OF_CONDUCT.md, CONTRIBUTING.md), branch protection rules, and review standards to define legal, ethical, and workflow expectations.",
+        "id": "repository-governance",
+        "label": "Repository Governance",
+        "stack": {
+          "exampleConfigFiles": [
+            "LICENSE",
+            "CODE_OF_CONDUCT.md",
+            "CONTRIBUTING.md"
+          ],
+          "exampleTools": [],
+          "notes": "Spell out contributor responsibilities for tests, documentation, and review so expectations are clear for Python-focused teams.",
+          "optionalFiles": [
+            "CODE_OF_CONDUCT.md",
+            "CONTRIBUTING.md"
+          ],
+          "requiredFiles": [
+            "LICENSE"
+          ],
+          "verification": "LICENSE file is present in the repository root; CODE_OF_CONDUCT.md and CONTRIBUTING.md are present for contribution guidance."
+        }
+      }
+    ],
+    "optionalEnhancements": [
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "observability"
+          }
+        },
+        "description": "Standardize error handling and structured logging to make debugging and production monitoring easier.",
+        "id": "observability",
+        "label": "Observability (Logging & Error Handling)",
+        "stack": {
+          "exampleConfigFiles": [
+            "logging configuration files",
+            "pyproject.toml"
+          ],
+          "exampleTools": [
+            "structlog",
+            "loguru"
+          ],
+          "notes": "Use structured logging for Python services and ensure critical paths record enough context to debug issues after the fact.",
+          "verification": "Confirm that a structured logging setup (such as structlog or configured logging with JSON formatting) is in place and that critical paths log enough information to debug failures in production."
+        }
+      }
+    ],
+    "recommended": [
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "test"
+          }
+        },
+        "description": "Test how components interact with each other and external systems, running after unit tests with more relaxed coverage thresholds.",
+        "id": "integration-testing",
+        "label": "Integration Testing",
+        "stack": {
+          "exampleConfigFiles": [
+            "tests/integration/"
+          ],
+          "exampleTools": [
+            "pytest"
+          ],
+          "notes": "Separate integration tests from unit tests, using fixtures to handle databases, services, or other external systems.",
+          "verification": "Confirm there is a separate integration or API test suite (for example, a dedicated tests/integration directory) and run it to verify interactions with databases, services, or external systems."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "performance"
+          }
+        },
+        "description": "Establish performance baselines and monitor for regressions using lightweight benchmarks or audits in CI.",
+        "id": "performance-baselining",
+        "label": "Performance Baselines",
+        "stack": {
+          "exampleConfigFiles": [
+            "pytest.ini",
+            "pyproject.toml"
+          ],
+          "exampleTools": [
+            "pytest-benchmark",
+            "cProfile"
+          ],
+          "notes": "Use simple benchmarks or profiling runs to characterize bottlenecks and watch for regressions in critical workflows.",
+          "verification": "Identify and run the configured performance checks or benchmarks (for example, pytest-benchmark or cProfile-based scripts) and confirm that their results are recorded and compared over time."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "quality"
+          }
+        },
+        "description": "Measure cyclomatic complexity or similar metrics to keep code maintainable, starting as a warning-only check.",
+        "id": "complexity-analysis",
+        "label": "Complexity Analysis",
+        "stack": {
+          "exampleConfigFiles": [
+            "radon.cfg"
+          ],
+          "exampleTools": [
+            "radon"
+          ],
+          "notes": "Use radon or similar tools to track complexity of Python functions and keep new code within acceptable limits.",
+          "verification": "Run the configured complexity tool (for example, radon) on the codebase and review the report to ensure new or heavily changed functions are not excessively complex."
+        }
+      },
+      {
+        "ciHints": {
+          "azure-devops": {
+            "stage": "quality"
+          }
+        },
+        "description": "Run accessibility checks on web-facing components to detect critical issues and improve inclusive UX.",
+        "id": "accessibility-auditing",
+        "label": "Accessibility Auditing",
+        "stack": {
+          "exampleConfigFiles": [],
+          "exampleTools": [
+            "pa11y"
+          ],
+          "notes": "Use headless browser-based tools to scan Python-backed web UIs for accessibility issues on high-traffic routes.",
+          "verification": "For Python-backed web UIs, run the configured accessibility tooling (for example, pa11y or axe via a headless browser) against key routes and verify that critical issues are fixed or tracked."
+        }
+      }
+    ]
+  },
+  "ciSystems": [
+    "azure-devops"
+  ],
+  "meta": {
+    "complexityChecks": {
+      "description": "When supported by the stack, run cyclomatic complexity or similar metrics in CI as a warning-only check initially.",
+      "enabledByDefault": true
+    },
+    "defaultCoverageThreshold": 0.8,
+    "migrationGuide": [
+      {
+        "description": "Start by adding pre-commit hooks and core formatting/linting so developers get fast feedback without touching CI.",
+        "focusIds": [
+          "pre-commit-hooks",
+          "linting",
+          "code-formatter"
+        ],
+        "notes": "Keep hooks fast and focused on changed files to avoid slowing down day-to-day work.",
+        "step": 1,
+        "title": "Establish Local Safety Nets First"
+      },
+      {
+        "description": "Introduce CI quality gates that mirror local checks, but treat existing violations as warnings wherever possible.",
+        "focusIds": [
+          "ci-quality-gates",
+          "linting",
+          "code-formatter",
+          "commit-linting"
+        ],
+        "notes": "Use diff-based tools or baselines so only new violations break builds; legacy issues remain visible but non-blocking.",
+        "step": 2,
+        "title": "Mirror Local Checks in CI (Soft-Fail on Legacy)"
+      },
+      {
+        "description": "Enable type-checking, coverage thresholds, and dependency/vulnerability scanning with gradual enforcement.",
+        "focusIds": [
+          "type-checking",
+          "unit-test-runner",
+          "unit-test-reporter",
+          "dependency-security"
+        ],
+        "notes": "Pin tool and runtime versions in CI and containers to avoid flaky differences across environments.",
+        "step": 3,
+        "title": "Add Type Safety, Coverage, and Dependency Security"
+      },
+      {
+        "description": "Add documentation standards, governance files, integration testing, performance baselines, complexity analysis, accessibility auditing, and (optionally) ML-specific practices for data-heavy Python repos.",
+        "focusIds": [
+          "documentation",
+          "repository-governance",
+          "integration-testing",
+          "performance-baselining",
+          "complexity-analysis",
+          "accessibility-auditing"
+        ],
+        "notes": "Tackle recommended items in order of business value; backend-only repos can skip web-focused checks like accessibility. For AI/ML-heavy Python teams, consider extending containerization with data versioning (DVC) and unit tests with data quality checks (e.g., Great Expectations) as part of this step.",
+        "step": 4,
+        "title": "Layer in Docs, Governance, and Recommended Checks"
+      }
+    ],
+    "qualityGatePolicy": {
+      "description": "New quality checks should warn on existing code and fail CI only for violations introduced in new or changed code, to reduce friction on legacy codebases.",
+      "preferSoftFailOnLegacy": true
+    }
+  },
+  "stack": "python",
+  "stackLabel": "Python",
+  "version": 1
+}