Public-works IoT automation jobs must meet a shared Python style guide before code reaches CI. Which practice enforces that earliest?
Select an answer to reveal the explanation.
Short Explanation
You can catch style problems before they travel: a pre-commit hook blocks a local commit when linting or formatting rules are violated. That’s kinder to your team than discovering inconsistent code in CI—or in production logs.
Full Explanation
Public-works IoT automation jobs that must meet a shared Python style guide before code reaches CI need an enforceable gate as early as possible. A pre-commit linting or formatting hook checks code on the developer’s laptop and fails the commit when rules are violated, catching inconsistent indentation, unused imports, or formatter drift before they enter shared branch history or consume CI time. CI can still re-check compliance as a safety net. Waiting for production outages to reveal inconsistent indentation is reactive and does not systematically enforce style. Manually reformatting only files selected for executive demos leaves other changes unchecked and the broader codebase ungoverned. Storing style rules in a slide deck without tooling integration communicates expectations but cannot reject a noncompliant commit. Exam caveat: pre-commit hooks complement CI linters; when a question asks for the earliest enforcement, a local hook is earlier than a pipeline-only check. Practical check: introduce a deliberate style violation, attempt a commit, confirm the hook blocks it, fix the issue with the formatter or linter, and verify the commit then succeeds and CI stays green. Pin the formatter configuration and tool version in the public-works repository so every laptop applies the same rules as CI; differing versions can undermine early enforcement.