March 12, 2020 at 12:00 am
Comments posted to this topic are about the item Build the VCS Habit
March 17, 2020 at 8:51 am
the easiest thing we've come across is
azure devops, git and Redgate source control
honestly - I can spin up a repository in 1 minute then let management studio do the heavy lifting to commit and push the code to source control.
I have version history of 60 or 70 key databases (I keep adding to it).
Redgate source control has been instrumental in this, I can compare systems quickly (in multiple windows) and just leave it running in one monitor while I continue to code.
MVDBA
March 17, 2020 at 12:36 pm
I completely agree with you, Steve. At my previous job we used Visual SourceSafe (VSS). We struggled to try and use TFS, but never got it right, so we used VSS the whole the the agency existed until it was closed. In my current job we use TFS, using TFVC.
For more than a year I've been teaching myself to use Git, because of its distributed nature. Git works wonders for commuters who have to travel long distances with no connectivity to anything. I've talked to my boss about the possibility of our switching from TFVC to Git, but it isn't likely to happen. Still, TFVC through the TFS front-end is fine.
But just because one uses TFS/TFVC (or any other VCS) doesn't mean that they use it correctly. That is an issue I struggle with a lot with one of my co-workers. We're on a team together working on a project. My coworker has a tendency not to do a Get Latest (a "pull" in Git terms), so what he'll do is have some old version of code, then down the line he'll make modifications to it and check his changes in, wiping out everything that others have done. Because its just he and I working on this project, he wipes out my changes. My fixes to problems brought up by users. That then results in the users complaining that "it's broken again". Which results in me having to go back and redo what I've already done. The worst time of this was one software module that I "fixed" over and over again for 6 weeks. (I tend to think that when something goes wrong its my fault, so I allowed myself to believe I'd made mistakes for 6 weeks until I finally realized that it was my coworker's fault, wiping out my changes every time he made changes to the code.)
My problem is compounded by the fact that where I work they don't train people on anything. They depend upon them learning by Binging/Googling or watching some YouTube video, and God only knows how good those are.
So, this leads me to ask, under these circumstances what can I do to get this guy to actually learn how to do a Get Latest before he starts modifying my code?
Rod
March 17, 2020 at 1:06 pm
My employer has been discussing for what seems like years about putting databases under VCS. One system that I support was developed by an outside contracting firm. Their database makes extensive use of stored procedures and whenever I'm debugging that web app, I have to open SSMS and locate the stored procedure that it calls. Since the DBAs aren't scripting the databases and putting the files into VCS, I scripted those databases and put the files into SQL folders in the C# project and put those files into VCS (we use Subversion for our VCS).
March 17, 2020 at 1:46 pm
I completely agree with you, Steve. At my previous job we used Visual SourceSafe (VSS). We struggled to try and use TFS, but never got it right, so we used VSS the whole the the agency existed until it was closed. In my current job we use TFS, using TFVC.
For more than a year I've been teaching myself to use Git, because of its distributed nature. Git works wonders for commuters who have to travel long distances with no connectivity to anything. I've talked to my boss about the possibility of our switching from TFVC to Git, but it isn't likely to happen. Still, TFVC through the TFS front-end is fine.
But just because one uses TFS/TFVC (or any other VCS) doesn't mean that they use it correctly. That is an issue I struggle with a lot with one of my co-workers. We're on a team together working on a project. My coworker has a tendency not to do a Get Latest (a "pull" in Git terms), so what he'll do is have some old version of code, then down the line he'll make modifications to it and check his changes in, wiping out everything that others have done. Because its just he and I working on this project, he wipes out my changes. My fixes to problems brought up by users. That then results in the users complaining that "it's broken again". Which results in me having to go back and redo what I've already done. The worst time of this was one software module that I "fixed" over and over again for 6 weeks. (I tend to think that when something goes wrong its my fault, so I allowed myself to believe I'd made mistakes for 6 weeks until I finally realized that it was my coworker's fault, wiping out my changes every time he made changes to the code.)
My problem is compounded by the fact that where I work they don't train people on anything. They depend upon them learning by Binging/Googling or watching some YouTube video, and God only knows how good those are.
So, this leads me to ask, under these circumstances what can I do to get this guy to actually learn how to do a Get Latest before he starts modifying my code?
Disciplinary actions. If you're not his boss, talk to him about incentivizing him to do it. "if you can do this for three weeks without fail, I'll buy you a beer". Or, just talk to his boss about it, and let them use the stick instead of the carrot. If he continues to cause issues to the productivity of the team, then he is negatively impacted until he either changes his ways or is managed out.
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
March 17, 2020 at 2:41 pm
So, this leads me to ask, under these circumstances what can I do to get this guy to actually learn how to do a Get Latest before he starts modifying my code?
He should be receiving merge conflicts, and likely is ignoring them.
Let's say there is proc A. You both pull the code down and have a copy. Now, you modify Proc A to A.1 and commit this back. This gets deployed, and the state is:
Prod: Proc A.1
VCS (central): Proc A.1
Your VCS: Proc A.1
His local VCS: Proc A
Now, at some point he modifies Proc A, but his changes will be Proc A.2
At this point, when he commits, he should get a conflict because Proc A has changed in the VCS differently than what he had. His git system (or TFS) should note that Proc A.1 and A.2 are different and need to be resolved. He can merge them somehow, or just delete your changes and keep his. Since this is just text, if he doesn't actually check this on a SQL Server, it could be wrong, or it could be fine. Either way, the committer gets the merge conflict and resolves it.
If prod now gets Proc A.2, without your A.1 changes, your co-worker has removed them.
Other than letting management know this person is removing code and having them handle it, there's nothing you can really do. I'd reassign all tickets to him with a note that the fix is in the VCS and he should find it in history and fix the current version.
March 17, 2020 at 2:43 pm
My employer has been discussing for what seems like years about putting databases under VCS. One system that I support was developed by an outside contracting firm. Their database makes extensive use of stored procedures and whenever I'm debugging that web app, I have to open SSMS and locate the stored procedure that it calls. Since the DBAs aren't scripting the databases and putting the files into VCS, I scripted those databases and put the files into SQL folders in the C# project and put those files into VCS (we use Subversion for our VCS).
Getting everyone to have a habit is important. You can certainly repeat this process regularly, and capture changes that way. However, if anyone making changes doesn't get the code from the VCS and commit it back, this will fall down at some point.
March 18, 2020 at 10:36 am
My employer has been discussing for what seems like years about putting databases under VCS. One system that I support was developed by an outside contracting firm. Their database makes extensive use of stored procedures and whenever I'm debugging that web app, I have to open SSMS and locate the stored procedure that it calls. Since the DBAs aren't scripting the databases and putting the files into VCS, I scripted those databases and put the files into SQL folders in the C# project and put those files into VCS (we use Subversion for our VCS).
you really need Redgate sql source control - it scripts up everything that has changed and can put it into source control with 2 mouse clicks.... if only I could persuade them to put the API back in place 🙂
MVDBA
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply