Several city departments import a shared module that syncs SSO group membership. The module's maintainers need a practice that keeps updates safe for every consumer. Which choice is best?
Select an answer to reveal the explanation.
Short Explanation
A shared SSO sync module is like a citywide tool crib—label the versions and don't snap the handles off without telling everyone. Version it, document the API, and coordinate breaking changes.
Full Explanation
When several city departments import a shared module that syncs SSO group membership, maintainers must treat the module as a multi-consumer platform dependency. The best practice is to version the shared module, document its public functions, and avoid breaking changes without a coordinated release. Semantic versioning, changelogs, and clear public APIs let consumers upgrade deliberately and keep SSO sync behavior consistent citywide. Letting each department fork an undocumented private copy with conflicting APIs multiplies drift: fixes land unevenly, group-sync bugs diverge, and institutional knowledge fragments. Committing SSO admin passwords inside the module source exposes privileged credentials in every clone and CI log—secrets belong in a vault or secret store, never in shared source. Deleting the module and pasting duplicate sync code into every department repo recreates the fork problem inside each repository and increases the cost of security patches. Exam caveat: mark deprecated APIs, provide migration guides for breaking majors, and keep backward-compatible minors when possible so departments are not forced into emergency synchronized cutovers. Operational check: publish a versioned release with documented exports, run consumer smoke tests against SSO group sync in a non-production directory, ensure no credentials are present in the module tree, and announce breaking changes with a coordinated municipal release window.