how to manage branches?

deebo

Hello,
Apologies if this is a remedial question but I'm having a hard time understanding the branching process when working with Source Control. I've read the online docs and the main piece I'm not understanding is unlinking/ linking to the branch. What do I "repoint" to? I have a local repository established and my remote repository is github which I manage using Source Tree. When I create a branch using Source Tree there is nothing like a folder that is created within my local repo, as far as I can tell, therefore there is nothing to repoint to. I think there is a important piece that I am missing here.
Any input would be greatly appreciated.

AlexYates

You are right. It sounds like those docs were aimed at TFS/SVN style source control systems which manage branching differently.

If using Git you can switch branch using Source Tree or raw git commands etc as you like. Then, on the database you'll want to go to the Get Latest tab, select any changes and click "Apply changes". (I'm assuming you linked using the "Git" option. If you linked using the "Working Folder" or custom hook file option the process is the same accept the button is called "Get Latest", not "Apply changes".)

Altternatively, you could provision a new database for the other branch. Some people prefer to do it this way because making wholesale changes to a database if the branches are very different can be ... fun. Especially if there are lots of table refactors/migration scripts involved.

I hope you are using the dedicated model. Doing this in the shared model sounds like a nightmare from a provisioning/team workflow perspective.

deebo

Right now I'm doing a proof of concept so I'm testing out a variety of setups that might work with our existing software constraints. Our current setup does not allow for the dedicated model but it is looking like that would be the way to go in the future, especially if we're branching.

As for the branching, you are correct. If I switch branches in SourceTree then it will be reflected automatically in SSMS/Source Control. I did not notice how Source Control tells you the branch it is looking at in the top right until just now. However, the only way I was able to get this change to show was to close and restart SSMS. No amount of waiting/ refreshing would do it, which is unfortunate.

Thanks for the response Alex. This helps to put me on the right track.

AlexYates

No worries, glad to help.

And I'd be interested to know why the dedicated model is impossible with your existing constraints. I've not yet found any technical constraints that cannot be resolved and I'm pretty sure it is impossible to be agile with a shared database and more than 3 developers.

Alex

deebo

Not impossible. I just need to be able to make the case for:
1. making database structure/ data management changes
2. users adopting (and getting trained up in) github/SourceTree/SourceControl/general version control philosophy

I'm not the DBA so I don't have the keys to the castle and yet #1 is still the easiest. The existing model (or lack thereof) is completely open access editing to a single development database. We only have a few editors but we want to get away from this for probably obvious reasons. However, any time a "thou shalt" is handed down from above and it makes a users life harder in the short term there is going to be some level of pushback, at least in my environment. Currently they make an edit and hit run. If we adopt this there are going to be a half dozen more hoops to jump through. I need to be able make a strong case for why the change is beneficial.

I hope that helps.
Thanks again!

AlexYates

In my experience DevOps is an enabler, not a hoop to jump through. If people are seeing it as hoops they have the wrong idea. The purpose of DevOps is to enable them to respond quickly. Part of DevOps is the freedom to branch, fix, merge, build, test and deploy, in a mostly automated fashion, in minutes. The hoop is simply that theyneed to learn to use modern technologies. And if you start a career in IT and you don't see staying up to date with modern technologies as pert of your job you were mis-sold.

Regarding the users adopting and getting trained up in Git: While Git is undoubtedly the obvious VCS in 2017, it is possible to adopt DevOps using a different VCS. These users, are they developers? If so they need to wake up to the fact that version control is non-negotiable in modern software development - regardless of the software language they use.

deebo

There is an opportunity cost to be acknowledged with this, which is all I'm getting at. I am the nominal "IT" staff in support of an engineering group. You may be 100% technically correct in the need for VCS but there is an interpersonal aspect to everything. Showing up and telling them they have the wrong idea and need to wake up is not really going to fly.

gnanasekar

Start with a simple strategy and evolve as needed.
Use consistent naming conventions for branches. ...
Frequently reverse integrate (RI) and merge into your main branch.
Encourage consistent code reviews - garbage in, garbage out.
Implement a CI/CD pipeline,

You can get more information here! https://goo.gl/rZiVVN