In this post I want to cover more thoughts about SQL Server professionals using version control. Because I have had some interesting conversations since my last post about it.
In a previous post I covered how SQL Server professionals can benefit from using version control. Which you can read in detail here.
Now I want to clarify a few things relating to it as well.
What
In my last post about it I mentioned storing scripts in version control. To clarify this, most things that can be broken down into code can be stored easily in version control. Including the below items which SQL Server Professions use often.
- Ansible/Chef/DSC/Puppet scripts
- ARM templates for Azure deployments
- Docker files
- Jupyter notebooks
- MS-DOS batch files
- SQL Server code
- Powershell scripts
- Power BI dashboards
- SSRS reports
- Teraform files
- Various other YAML files
In fact, I could carry on for a long time with this list.
Other files
In reality, you can store other file types in version control. However, if you intend to share these other files and they are changed a lot be aware that over time they can have potential issues.
Benefits
Now and again I have been in conversations where database professionals have discussed creating and running scripts. Often the location of the files has been on a share somewhere.
If you read my previous post you will see some downsides to doing this. Especially the interesting methods some people use to manage their scripts. Using version control to manage your scripts is so much easier. Just one name in the same location every single time.
Operation teams are reaping the benefits of using version control. Especially since sharing the code makes your team more productive. In addition, reporting specialist are finding that keeping their report schemas in version control avoids the wrong ones being used.
In addition, I can assure you that keeping your scripts in version control comes across as a lot more professional than a file share somewhere.
Source of automated deployments
If you are using version control in a service like Azure DevOps or GitHub there is another advantage. Which is that whatever you have in version control can be used as the source of CI/CD deployments.
For example, say you have a Git repository in Azure DevOps which has SQL Server database updates in it.
You can then use Azure Pipelines to build a dacpac file based on that code. From there you can deploy the database updates to one or more SQL Servers.
In fact, you can take this one step further. For instance, you can use the Kevin method I described in a previous post here to have multiple dacpacs created for use with different SQL Server and Azure SQL databases.
All of which can be done within one deployment and allows you to still keep one source of truth within a repository.
Just one of many ways you can be creative with how you use your version control with CI/CD deployments.
DevOps
A lot of companies are encouraging teams to work in a DevOps related kind of way. Even when working with databases as you can see in the ‘2020 State of Database DevOps’ report. Which you can read in detail here.
Version control knowledge will be essential for this. Even if you do not use it right now it does not mean you can avoid using it in the future.
Intellectual property gotcha
On a side note I must remind you all about one thing. If you are keeping your code to yourself because of intellectual property you might want to read your employment contract.
Because these days it is common practice for them to state that whatever you develop on your work machines is the property of the company. Bear this in mind if you are being protective of your code.
Of course, turning this around it also means that if you have an awkward colleague who is reluctant to share you can remind them of this fact.
Final word
I hope this post which covers more thoughts about SQL Server professionals using version control is useful.
I really want more SQL Server Professionals to start using it. Because the landscape of our industry is changing, and we must adapt to it.
My advice is that if you have not started using version control yet look to do so. Start small and build from there.
[…] Kevin Chant shares some thoughts: […]