311 developers need a safe way to change request-table schema without committing straight to main. Which workflow should they follow?
Select an answer to reveal the explanation.
Short Explanation
Feature branches and PRs for 311 schema are the ‘propose the street closure before you dig’ workflow—review first, then merge, don’t jackhammer main at noon.
Full Explanation
311 developers changing request-table schema safely should use feature branches and pull requests rather than committing straight to main. That workflow isolates DDL edits, enables review and CI validation on the SQL Database Project, and only merges after checks pass—preventing half-reviewed request-table changes from landing on the shared trunk during business hours. Editing production tables live during business hours with no review risks outages and untracked drift from the project model. Sharing one database login password in team chat for DDL destroys accountability and credential hygiene. Overwriting main nightly from a single developer workstation erases collaborative history and bypasses PR gates. Exam caveat: long-lived feature branches can drift; keep schema branches short and rebase/merge often. PR review should include publish preview/diff against a target so reviewers see destructive changes (drops/nullability) before merge. Environment approvals for production remain separate from branch/PR policy. Operational check: create a feature branch, alter request-table DDL in the project, open a PR, confirm CI build/tests run, require a reviewer approval, merge, and verify main and the next pipeline deploy reflect the change without any direct production SSMS edit.