Today I received an email from someone who had just inherited a GitHub account from a former employee. He asked, "What do I do with this?"
His organization is not a "development" shop. They support business systems, ERP systems, SQL Servers, SharePoint, PowerApps, SSRS, etc. They don't code C# and JavaScript and Python.
So the GitHub repositories under this account were being used to store various files that are ostensibly "source code", but they were not Visual Studio projects with 6 branches and 5 developers flinging code around. They were files like SQL scripts.
One question was: How do I access and work with SQL scripts in GitHub? Can I use SQL Server Management Studio to access the files in GitHub?
Interesting question. I don't think SSMS can work with GitHub, but...
At GPUG Summit 2018 in Phoenix, Jonathan Cox demonstrated during the SQL Server shootout that VS Code can be used to work with SQL scripts, and it can also work with GitHub. So in theory, you could use VS Code to work with SQL scripts in GitHub.
But what about the other file types that are not related to VS Code?
The person shared that they have traditionally managed their "code" type files in SharePoint, along with other customer deliverables.
"Sounds like a pretty good system", I shared. Why bother using GitHub at all?
They used to store files in SharePoint, but with all of the talk about Git these days, the former employee apparently thought that a formal source code control system was a best practice for their small organization, even though they are not a development shop.
Personally, I don't think GitHub, or Git, makes much sense for such company. If everyone in the company, including non-technical consultants, is able to zip up project files, name them with a date and version, and save them in SharePoint, that sounds like a pretty darn good plan to me. It's simple, it meets their needs, and it's a practice that any non-technical person in the organization can easily follow.
If you aren't writing "code", don't need branching, don't have multiple developers working on the same code at the same time, and don't need proper version control, I don't necessarily think you need a formal source code control system, let alone the more complex Git and GitHub. If you have a good practice where people check in copies of "released" or "deployed" files in Sharepoint, and if that works for you, I say go for it.
I did consulting for years without using a version control / source code control system. If I was writing code, after each build, I would zip up the code and make sure it was backed up. I could then easily email that zip file to the partner or customer I was working with to ensure they had a copy as well. That system worked just fine for me and the companies I worked for.
Eventually I started using SVN Server for my source control, and it worked great. It gave me the benefits of formal source code control, but was very simple to use, easy to maintain, and was 100% reliable.
After a few years, I had a project where I needed proper branching. I needed to deploy hotfixes to the production code branch while simultaneously having two open development branches. SVN Server just couldn't handle that scenario, so I setup an account on Bitbucket and learned how to use Git, which was no walk in the park.
But that is only for my code. I don't use Git for my SQL scripts or my Modifier & VBA modifications. So I wouldn't expect a non-development shop to use Git for their SQL scripts.
Find a system and process that works for your organization and meets your requirements. Take care of what matters, and don't worry about the technology du jour.
Steve Endow is a Microsoft MVP in
Los Angeles. He is the owner of Precipio Services, which provides
Dynamics GP integrations, customizations, and automation solutions.
No comments:
Post a Comment
All comments must be reviewed and approved before being published. Your comment will not appear immediately.