Does Version Control Scare You

  • Comments posted to this topic are about the item Does Version Control Scare You

  • Sadly, I view all such methodologies as technical debt driven.  In the misconceived world of Dev-Ops, I tend to see the fallacies and errors this kool-aid offers.  Making backups and having fool-proof fallback solutions continues to be the beat of the drum I march to.  Obtaining voice of the customer and doing it right the first time (test-test-retest) continue to propel me forward in my endeavors and career.  I realize I may be a small minority, yet I find I am constantly asked to fix what IaaC broke.  I also get a laugh when I quote my former mentor and boss, "I will fire the coder, not the poorly written code."

  • I like code management systems. I used an early system written by DEC back when I worked on VAX systems. The trick is remembering to use it regularly and keep production code safe. Where I am now, we have a fairly heavy dependency on Team Foundations, so I think it will be a while before there is any organized migration to Git within the company. But, at least we do use one, and it has saved my bacon a few times.

  • You know it does. We've talked about this. Why do you keep bringing it up?

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • I can't imagine working without source control.  It's like boxing with one hand tied behind your back.

    Be still, and know that I am God - Psalm 46:10

  • Grant Fritchey wrote:

    You know it does. We've talked about this. Why do you keep bringing it up?

    lol, wondering how (many) and how scared others are

  • david.gugg wrote:

    I can't imagine working without source control.  It's like boxing with one hand tied behind your back.

    same

  • jonathan.ellison wrote:

    Sadly, I view all such methodologies as technical debt driven.  In the misconceived world of Dev-Ops, I tend to see the fallacies and errors this kool-aid offers.  Making backups and having fool-proof fallback solutions continues to be the beat of the drum I march to.  Obtaining voice of the customer and doing it right the first time (test-test-retest) continue to propel me forward in my endeavors and career.  I realize I may be a small minority, yet I find I am constantly asked to fix what IaaC broke.  I also get a laugh when I quote my former mentor and boss, "I will fire the coder, not the poorly written code."

    Version control doesn't replace anything you mentioned. It works in conjunction.

    VCS also doesn't protect us from poor coders. Those exist with our without VCS, however it does let us know what thing they changed.

  • I am a developer and as you suggested using source control is second nature for developers. I hesitated before answering since I felt you were asking DBAs. However, I am also our TFS Administrator and GitHub Administrator, so I have insight into how DBAs, at least where I work, use source control. Or, as in our case, don't use source control. I work for a large state government department, which means that we're always short of money. In the GitHub world for business we purchase a GitHub Enterprise license and enough of what GitHub calls "seats" which I distribute to all of our developers (including myself). I have enough GitHub seats to cover all of our developers and contractors. Then some more to cover some of our Project Managers (PM). For the PM's I add them to the Triage role in the repos I add them to, those they manage. This allows them to see the code and even clone it (if they want to), but mostly it gives them the ability to write to the repo's Wiki and create and assign GitHub issues. But they cannot commit any changes to the code.

    However, for the DBAs none of them have a GitHub seat. We're ending our current fiscal year at the end of June. I've discussed with our Deputy CIO the need to get more GitHub seats for the DBAs, however it isn't going to happen. And it all goes back to the budget. So, the DBAs are going to continue doing what we all did back in the mid-90's, and that's copy all their SQL code to some folder on some server. They'll put the code into a folder with the date appended to the folder's name. They've done this for decades. Yeah, the server is backed up, but dang, I'd hate to try and remember what you did in some folder with a date of 20170412.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • david.gugg wrote:

    I can't imagine working without source control.  It's like boxing with one hand tied behind your back.

    Yeah, in all seriousness, I can't imagine not using it. Heck, I use it for programming my radios.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Rod, they could set up a central Git server, no cost at all, locally and then use that. It's going to be all command line driven (although I'm sure there's a Git gui somewhere), but they'd at least have a way to manage changes & such better than a file in the file system.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • I'm one of those people not using source control, not out of fear of it, but more out of "most all my code is one-offs and what the heck is a "pull" and why does it sound like you're actually "pushing" code with a pull?"

    One of my co-workers (who came over from a developer background,) did set up a Git repo, but while he's a nice guy, he's not exactly a good instructor.

    I'm thinking of, at some point, giving Steve's old article a try to get a self-hosted Git repo going at home, just to get a feel for how it works and how to use it, at which point I'll probably change my tune at work (much to the delight of my aforementioned co-worker, I'm sure.)

  • It's a pull because you're asking someone to accept your code. You pushed it into the Pull Request, but they don't have to take it. They have to pull it.

    It sounds crazy, but makes sense. I sent a PR to Microsoft for a change to one of the articles on MS Learn. They agreed I did something good and "pulled" the code from my repo for the update.

    Even with one-offs, what I find is I do something silly and change it, and then realize my change was silly-er. So I want the older version. The more I just drop stuff and commit it, the more I just try stuff, knowing I can easily go backwards. Plus it's logged in case what I did actually mattered to anyone else and they wanted to know when I did it 😉

    Rod, what Grant said. Just make the folder the DBAs want to use a git repo. They can just keep dropping files. Then you can commit them 😉

  • It's a pull because you're asking someone to accept your code. You pushed it into the Pull Request, but they don't have to take it. They have to pull it.

    It sounds crazy, but makes sense. I sent a PR to Microsoft for a change to one of the articles on MS Learn. They agreed I did something good and "pulled" the code from my repo for the update.

    Even with one-offs, what I find is I do something silly and change it, and then realize my change was silly-er. So I want the older version. The more I just drop stuff and commit it, the more I just try stuff, knowing I can easily go backwards. Plus it's logged in case what I did actually mattered to anyone else and they wanted to know when I did it 😉

    Rod, what Grant said. Just make the folder the DBAs want to use a git repo. They can just keep dropping files. Then you can commit them 😉

  • I started using Visual Studio SSDT (database projects with a dacpac output) for all SQL Server databases years ago. This simplified deployments between environments to the point where deploying our databases to any environment is fairly trivial.

    The hardest part for me, and most people I've dragged into this (who, while kicking and screaming in the beginning, now express sincere gratitude at being dragged here) was getting past the idea that the server is the system of record for what your database objects should be. Once we transitioned to the paradigm where it is the definition of the database in code that dictates what the servers should look like, everything just clicked and now deployments to dev, test, prod, stage, someone's laptop, a client site not even connected to us... etc etc. are all just the double click of our (usually less than 10 lines) powershell dbSetup.ps1 file or Azure DevOps pipeline task.

    Once you're here, GIT, TFS, Subversion is just a no brainer, of course we're going to have our database in source control it's really just code (and yes that includes seed data). Any fear I had of Version Control faded a long time ago. Oddly enough right at the same time I no longer feared that I didn't keep the right version of a script or remember all the different settings that I had to set, and tests ... really... we do that now... so that's awesome ... . Code reviews... hey we do that too, we pretended before but now with Version Control we actually review code not just rubber stamp it.

Viewing 15 posts - 1 through 15 (of 29 total)

You must be logged in to reply to this topic. Login to reply