Opinions expressed on this site are solely those of Kendra Little of Catalyze SQL, LLC. Content policy: Short excerpts of blog posts (3 sentences) may be republished, but longer excerpts and artwork cannot be shared without explicit permission.
on August 26, 2019
I’m really excited for Redgate’s new SQL Change Automation plugin for SQL Server Management Studio (SSMS). SQL Change Automation lets DBAs and developers use a migrations-first approach to create precise scripts to apply changes to your database. If you’re curious about what I mean by “migrations-first”, read more about this approach, and how it compares to a state-first approach here.
I’ve been working with SQL Change Automation with Git for a while in Microsoft Visual Studio. Visual Studio contains a lot of integration by default with Git and Azure DevOps, so I’ve been using its graphical tools, for the most part.
The new SQL Change Automation extension for SSMS works with the Version Control System (VCS) of your choice, but this initial release provides only “working folder” support
That means that you set up your version control outside of SSMS, then point SQL Change Automation at your working folder.
This inspired me to start learning the Git command line. I’m not a command line guru of any sort, but it turns out the Git command line is really easy to learn, and I think it’s super fun to use. In this 22 minute video, I give an overview of how to create a fresh repo in Azure DevOps and clone it to your local machine, set up a new SQL Change Automation project in SSMS for the Microsoft pubs sample database, commit changes to source control, work with branches, and stash files away when you need to.
A reference for the Git commands run with the times they are demonstrated is right below the video
00:40 Where to get the code to create the Pubs database
01:00 Creating a new repo in an Azure DevOps project
01:39 Clone the repo to your local machine with: git clone urlfromyourrepogoeshere
03:00 git status
03:30 Create a new SQL Change Automation project and baseline it in SSMS
06:00 Stage the files with: git add .
06:40 Review staged files with: git status
07:33 Commit the files with: git commit -m “commit message goes here”
08:08 Send commit to upstream repo with: git push
09:42 Create a feature branch with: git checkout -b foldername/branchname
10:25 Add a new migration script with SQL Change Automation extension in SSMS
11:36 Observe how non-committed files in working directory act in Git when changing branches
13:04 Put away / temporarily remove “dirty” files with: git stash -u
16:02 List local branches with: git branch
16:11 Switch to an existing branch with: git checkout foldername/branchname
16:17 Unpack / get back your stash with: git stash pop
16:58 Stage modified files in our feature branch with: git add .
17:03 Commit modified files in our feature branch with: git commit -m “commit message goes here”
17:33 Get detailed syntax to push feature branch for the first time to remote repo with: git push
18:07 View repo in Azure DevOps Services
18:22 View branches and create a pull request to merge our feature branch into master
19:05 Complete pull request, note I use an option that deletes the feature branch on the central repo after merge
19:45 Validate that the feature branch still exists on my client machine with: git status
20:10 Return to master branch with: git checkout master
20:22 Clean up my local feature branch with: git branch -d foldername/branchname
20:40 Pull down updated code from master with: git pull