User profile for AlexYates

Hi Mary, Moving from TFS to Git is an excellent choice and your question is a very good one. The short answer to it, however, is "it depends". Everyone has their own views on the best branching strategy and it's a minefield of flame wars. For example, first read this article by Vincent Driessen. This is probably the most widely respected and referenced blog post about git branching on the internet. This branching model has become known as "gitflow": https://nvie.com/posts/a-successful-git-branching-model/ However, once you have read it, also read this blog post by Jussi Judin which calls out some of the common problems that some people see with gitflow. Essentially Jussi is arguing for trunk-based development because he feels it's better aligned with the principles of continuous integration and more natural for developers: https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ I'm sorry I don't have a simple answer for you - there is a big gap between theory and practice and ultimately you need to figure out how to bridge it for yourself. However, I would like to leave you with an exercise that I have run with various clients to help them figure out the best strategy for their team. I believe in two things: - You should avoid cherry picking changes from one branch or another. Branches should be tested and deployed in their entirety for effective, repeatable testing and simpler deployments. - Your branching strategy should mirror your project management style. You can read all the books you like about DevOps, continuous delivery and branching models, but ultimately if the way you manage your code does not match the way you manage your projects, you will forever be cutting corners, breaking your own rules and creating headaches for yourself. For this exercise, I want you to begin by leaving your theoretical ideas about good and bad branching strategies at the door and consider the reality of the way you manage your development process and map that out as if it were a branching strategy. Since, in a perfect world, your project management style and your branching strategy would be aligned, you should consider whether the diagram you have drawn would be in any way sane if you used it as your git branching strategy. This gives you a starting point - then you should think about whether you could make any simplifications in your branching or project management strategies to make life simpler - considering everything you know about DevOps, continuous delivery and widely accepted branching good and bad practices - while also considering the preferences and abilities of your team. (E.g. avoid long-running feature branches, break down bigger tasks into smaller chunks, don't ask a developer who has never used git to follow a horribly complicated branching model.) For more info about my "reality branches" exercise: http://workingwithdevs.com/branching-reality/ I hope that's useful. Good luck! / comments

Hi Mary,Moving from TFS to Git is an excellent choice and your question is a very good one. The short answer to it, however, is "it depends". Everyone has their own views on the best branching stra...

0 votes

The folks at Redgate use GitHub. Microsoft use Git in Azure DevOps Services. https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/use-git-microsoft The Redgate tools will work fine with Git hosted in GitHub, Bitbucket, Azure DevOps Services (hosted) or Azure DevOps Server (TFS / on prem). The de facto source control technology these days is Git and it pays to use the most widely supported and understood tools. / comments

The folks at Redgate use GitHub. Microsoft use Git in Azure DevOps Services.https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/use-git-microsoftThe Redgate tools will work fine...

0 votes

Sounds like a sensible decision. Using pre/post should mean the "deploy to all workstations" step is just a simple "get latest"/"apply changes". / comments

Sounds like a sensible decision.Using pre/post should mean the "deploy to all workstations" step is just a simple "get latest"/"apply changes".

0 votes

Good morning, This is a tricky unusual case that isn't handled well out of the box. The problem is ordering. 1. SQL Compare tries to add the new column, but fails because of the NOT NULL constraint. 2. Data Compare squirts in the data, but it never gets to this point because step 1 has already failed. Possible work arounds: UNLINK/RE-LINK STATIC DATA 1. Unlink static data 2. Deploy new column as NULLABLE all the way up to prod 3. INSERT static data manually all the way to prod, or relink static data to source control and then deploy all the way to prod 3. Add NOT NULL constraint, commit to source control and deploy all the way to PROD 4. Re-link static data (if not already done so) This option is probably the simplest, but it requires a multi-step deployment. If you have short release cycles and a good DevOps maturity this should not be too big an issue, but if you have long release cycles and poor release management processes this can be a pain to manage. PRE/POST DEPLOYMENT SCRIPTS SQL Source Control has recently released a new feature which, at the time of writing, is still only available via the frequent updates release channel: https://documentation.red-gate.com/soc6/common-tasks/working-with-pre-post-deployment-scripts 1. Unlink static data and add a filter to ignore the table schema 2. Add a pre-deploy script to add the column as NULL, insert appropriate data and then apply the NOT NULL constraint. Your script needs to be rerunnable, so consider adding an IF EXISTS statement at the top and using a MERGE statement to squirt in the data. 3. Deploy the change all the way to production. 4. Remove the table filter and re-link the static data. Also, remove the pre-deploy script. Once the update has been deployed everywhere you don't need it any more. This option requires less manual intervention/project management but it does rely on more complex and bleeding edge features that have not yet been released on the regular SQL Source Control release channel. / comments

Good morning,This is a tricky unusual case that isn't handled well out of the box. The problem is ordering.1. SQL Compare tries to add the new column, but fails because of the NOT NULL constraint.2...

0 votes

Fair point, i suppose my instructions for option 1 should have read: UNLINK/RE-LINK STATIC DATA 1. Unlink static data 2. Deploy new column as NULLABLE all the way up to prod ****AND TO EVERY DEV WORKSTATION**** 3. INSERT static data manually all the way to prod ****AND TO EVERY DEV WORKSTATION****, or relink static data to source control and then deploy all the way to prod ****AND TO EVERY DEV WORKSTATION**** 3. Add NOT NULL constraint, commit to source control and deploy all the way to PROD ****AND TO EVERY DEV WORKSTATION**** 4. Re-link static data (if not already done so) In retrospect, perhaps the following is a better solution all round: PRE/POST DEPLOYMENT SCRIPTS (v2) 1. Unlink static data table 2. Add a pre deploy to: a. Check if target table is in the before state and that it already holds data b. If so, create a new table called OriginalTableName_Temp c. Copy all data to new temp table d. Truncate original table 3. Add a post-deploy to: a. check if OriginalTableName_Temp exists b. if so, copy all data, including new default data for new NOT NULL col into original table (by the time this script runs, the new col should exist). c. delete OriginalTableName_Temp 4. Commit your new pre- and post-deploy script, along with your new NOT NULL column as a single commit. 5. Deploy this change to all environments, including prod and all dev workstations 6. Re-link static data * For now, you probably need to manually patch all the other dev workstations. Sorry I forgot to include dev workstations in my original answer. Forgive me, I'm a only fallible human. :-) / comments

Fair point, i suppose my instructions for option 1 should have read:UNLINK/RE-LINK STATIC DATA1. Unlink static data2. Deploy new column as NULLABLE all the way up to prod ****AND TO EVERY DEV WORKS...

0 votes

Alessandro is spot on. Essentially you need to balance the need to manage all DBs as a single unit (because dependencies) and the need for agility (because if every DB is managed independently you don't need to get everyone to agree to release everything at once). In the centralised source control (TFTC/SVN etc) world folks tended to have bigger repos, but in the distributed (git) world folks tend toward smaller, isolated, dare I say, "microservices". Basically, if you plan to release DB updates for different dbs independently, you should probably have a repo per DB... Unless that's totally impractical because dependencies. And if that's the case you will probably need to group DBs together, but its also a good sign that you should try to remove some of those dependencies. / comments

Alessandro is spot on.Essentially you need to balance the need to manage all DBs as a single unit (because dependencies) and the need for agility (because if every DB is managed independently you d...

0 votes

Oof, that sounds fun. Good luck! / comments

Oof, that sounds fun. Good luck!

0 votes

You are right, that is nuts. EITHER: One DLM Dash install per team and the team is responsible for maintaining it - but that relies on each individual team having a neat division of responsibilities and not needing to look after more than 50. OR: Set up an automated process to drift check before deployment. https://documentation.red-gate.com/sca3/automating-database-changes/automated-deployments/handling-schema-drift OR: Build your own thing with triggers: https://www.red-gate.com/simple-talk/sql/database-administration/database-deployment-the-bits-database-version-drift/ OR do several of those. But 13 instances of DLM Dash really is nuts if there are people who will need to look at many different instances. / comments

You are right, that is nuts.EITHER: One DLM Dash install per team and the team is responsible for maintaining it - but that relies on each individual team having a neat division of responsibilities...

0 votes

Hi Annette, Off the top of my head, try: $project = "C:\Work\scripts" $targetDb = New-DatabaseConnection -ServerInstance "test01\sql2014" -Database "Test" $options = "ignoreadditional" Sync-DatabaseSchema -Source $project -Target $targetDb -SQLCompareOptions $options See example 6 here: https://documentation.red-gate.com/sca3/reference/powershell-cmdlets/sync-databaseschema And further docs here: https://documentation.red-gate.com/sca3/automating-database-changes/automated-deployments/using-sql-compare-options-with-sql-change-automation-powershell-module / comments

Hi Annette,Off the top of my head, try:$project = "C:\Work\scripts" $targetDb = New-DatabaseConnection -ServerInstance "test01\sql2014" -Database "Test"$options = "ignoreadditional"Sync-DatabaseSch...

0 votes

Not sure why that's not working, one for support I guess. In the meantime, reverting to the raw SQL Compare command line is my de facto quick fix where possible. / comments

Not sure why that's not working, one for support I guess.In the meantime, reverting to the raw SQL Compare command line is my de facto quick fix where possible.

0 votes

How can we help you today?

AlexYates

Comments