How do I pull down changes to my local dev database?

cgipson

I see plenty of tutorials on pushing changes from your local machine to the remote databases.  My question is, how do you pull down changes made by others when working in a multi-dev team?  Say another developer works on a separate feature and it gets deployed/committed to source control.  How do I pull down those changes and run the against my dev instance of the database?  

The SQL Change Automation project is stored in VSTS (git).  I want to enable my developers to always make sure they have the latest version on their local machine.  We utilize the git-flow branching strategy. 

Thanks in advance.

way0utwest

I think gitflow is unnecessarily complex, and it's problematic for databases, but if you use it, that's OK.

If you look at gitflow, you aren't putting your changes from the local machine to the remote db, are you?  You are sending your changes to the VCS and the SCA automation process should push them to another machine. However, that doesn't matter. You push/pull your changes from VCS, which is what other developers do.

First, you need strong communication if developers might touch the same object. That can be something like a Slack channel, or some other mechanism for a developer to just say "I've changed x". This important, otherwise you'll end up with hard merges. You could even make a quick "I'm doing this" in your standup.

Your gitflow should have feature branches, correct? This means you have

master---------o---o---------------------o
dev  --------0/----o/---------o--------o
fb1             \---o---\-o----/
fb2        \----o/

In this case, master is at the top, where I release. Dev is below. Let's have Steve work fb1 and Andy work fb2. Andy gets dev copied and then commits. He is happy with his commit (o) and pushes up to dev. This is the second o. This gets merged to master.
Steve later gets a branch from dev, fb1, and works and commits. Change is good. He then pulls from dev, which at this point, should include the change from Andy. Steve needs to merge this in his branch, which might be simple, might be hard. If there is communication, either there is no conflict or there is the need to resolve changes. Steve then commits again and pushes/merges changes to dev later.

The key here is that you need to have short lived branches for the db, since this is a shared area. If you need to work, make your branch and push changes that you know work, immediately. If you're not sure or this takes time, then stage changes and pull from dev again to get anything merged in. Then try applying your changes again. The really issue here is that the longer branches live, the more likely there are conflicts.

Imagine that you have multiple C#/Java developers working on the same method. If they each make a quick change and merge, the other likely gets the changes. If they wait weeks, merging might be really hard.

The same thing with databases. What I'd suggest if that you plan out changes, maybe get an idea, and save them after you've experimented a bit. This might be an hour or a week. Then rebuild the db branch again, essentially a new feature branch, and make your changes. If they're good, immediately commit and merge back to dev.