sql server - Database - Version Control - Managing dropped/deleted objects -
we want clean our database schema , drop/delete objects no longer being used.
we suspect sometime in future we'll want resurrect removed functionality.
we've discussed following options dealing dropped objects in version control:
deleting .sql files source control once gone database , relying on version history store definitions. our concern approach sometime on years source control moved , lose history. seems difficult know recover if can't see dropped objects.
leaving .sql files in source control updating definitions "drop proc {someproc}". approach our concerned leaving objects in version control no longer exists , risk losing history if vcs moved
creating new repo dropped objects , migrating .sql files repo once have been dropped sql server.
we're working in windows environment , new working vcs databases. git + ssdt.
currently option 3 our preferred approach.
i see lot database code, happens on time people end stuff in database either not used or not work (think proc references table , table modified not proc).
the thing in source control (which looks have) , create tag or branch of code before , after deleting can back.
two things transpire, either code genuinely never used or used @ year end , when find out, world fall on head better have quick way back.
of course if had full suite of tests year end process safe :)
i wouldn't use option 3, keep history in main branch keep history it.
ed
Comments
Post a Comment