How can we help you today? How can we help you today?
bobprobst
What's your source control on the back end?  I assume all the Development takes place in Dev - Is Stage like a Test\QA area?  Assuming so,  take away all the developers change rights in Stage and Prod.  Assign a gatekeeper for promoting changes from Dev to Stage and Prod. Have your devs use Object Locking in SSMS to ensure they're not overwriting each other's code.  It only takes one person making a mistake and losing hours of work for them to remember in the future.  (been there!) When Dev has functioning changes, use the Migrations tab to generate a migration script on the objects you want to promote. Track the changeset numbers generated by this.  If you're using TFS, you can associate it to TFS work items with #A[item number] in the comments during check in.  Never check in individual objects.  Always build a migration script to capture the change. When you're ready to promote Dev changes to Stage, run the migration scripts in the order created - ideally each migration script should result in functioning code. Even when an object is included in multiple Migration Scripts, if you run those scripts in the creation order, Stage will be guaranteed to match Dev.  This now becomes your migration plan.  The collected set of migration scripts can be run in Prod and yield the exact results as they did in Stage / comments
What's your source control on the back end?  I assume all the Development takes place in Dev - Is Stage like a Test\QA area?  Assuming so,  take away all the developers change rights in Stage and P...
0 votes
I'll assume you have a pretty large code base.  I work over VPN and some checkins take 5 minutes to complete.  Just enough time to browse reddit for 45 5 minutes. [image] / comments
I'll assume you have a pretty large code base.  I work over VPN and some checkins take 5 minutes to complete.  Just enough time to browse reddit for 45 5 minutes.
0 votes