Yeah, things get messy, no matter what model you choose for securing your PROD data:
- Create one user and give it all rights to the database
- Create specific users and give them the least amount of rights to do what is must, and no more
- Somewhere in between the previous 2
Truly, #3 is generally the answer. Let’s say that you give the application all the rights that any user of the system can have, and let the application dole out the rights to individuals. This is not a terrible plan, but I dare say that many databases contain data, or utilities that it is not desirable to give to the users. (My utility schema generally has tools to maintain and release code, something that you don’t want general users to have access to. And lest you have a developer working “with” you like I once did, you don’t want the application to have access to the tools to disable all of the constraints in the database, even if you have ETL uses for that code.)
Check it out for some examples.
For the advocates of python, a commonly used application is Jupyter Notebook. Jupyter Notebook is a server-client application that allows editing and running of python code via a web browser combining python code, SQL, equations, text, and visualizations. It also offers syncing with GitHub repositories.
More specifically, Jupyter Notebook will be rendered by GitHub directly on your repo page. This means that one can enjoy all the benefits that Git offers regarding version control, branching, merging and collaborative development when using Jupyter Notebook.
The best strategy is probably a multi-tiered strategy. It absolutely starts with source control, but it doesn’t have to end there.
I will assume that you already have TFS setup and are just using HTTP and want to make things a bit more secure with HTTPS. I am also assuming that you will be using port 443 for HTTPS traffic.
To update TFS to use HTTPS you need to do a couple of things:
Have a legitimate certificate installed on the server that you can bind to
Have an IP address on the server and have firewall access setup to that IP address on port 443
But there are a few more steps as well, so click through to see them all.
Of course, this just scratches the surface of using source control and Git. Now that you have a working example, I encourage you to read more especially about branching and merging, and your inevitable merge conflicts. I think branching is incredibly important if you like to tweak your scripts because it gives you a separate copy of your code to work on and test, and when you’re satisfied you merge your changes back to your master branch (or trunk).
Once you get the basics down, it’s really easy to start contributing other projects too! You could fork a project, work on it, and then submit a pull request to the owners to add features. Or, maybe someone will find code you made available and do the same. It’s amazing. Or a very minimum, this will get you up to speed on how you can introduce an SCM practice for SQL-related scripts at your workplace, if you don’t have one, or how you can start using it if you do (and don’t already).
Click through to see how Drew integrates Git with SQL Operations Studio. Spoilers: it’s pretty easy, given the relationship between SqlOps and Visual Studio Code.
This post is for a specific type of person if you are:
- New to source control
- Are getting started on your path to the continuous delivery nirvana
- Have been able to get your database into some sort of source control system
- Have more than one person checking in code to the database source
- You are unsure what yo do next
Then this post is for you!
This is a nice post with some next-steps for when you have a database in source control but aren’t quite sure what to do next.
@brianszadek says: I am looking to automate the scripting of objects with PowerShell for easier source control integration.
I thought this would be a little bit easier, but it looks like the SMO way of doing this is still fairly complicated. Maybe something I can look at simplifying for the project in a bit
If you want to get your database into source control but feel like it’s going to be a time-consuming challenge, this isn’t the time-consuming part.
I’m putting this together here for my own reference and to hopefully write it up in a way that helps things “click” for some people who need that extra nudge to get into “aha!” territory. A number of the examples I’ve seen elsewhere have mixed the command-line and GUI clients, but the more I use git GUIs, the less I like them for the basic workflow. You only need to know a handful of commands to be productive and for that, the command line beats the GUI in my opinion.
So, here we go. My GitHub workflow for working on dbatools, with as much command-line work as possible. This walk-through assumes basic familiarity with source control concepts.
This is a great guide for people who are not familiar with Git.
In general, code analysis is not just a help to the individual developer but can be useful to the entire team. This is because it makes the state and purpose of the code more visible, so that it allows everyone who is responsible for delivery to get a better idea of progress and can alert them much earlier to potential tasks and issues further down the line. It also makes everyone more aware of whatever coding standards are agreed, and what operational, security and compliance constraints there are.
Database Code analysis is a slightly more complicated topic than static code analysis as used in Agile application development. It is more complicated because you have the extra choice of dynamic code analysis to supplement static code analysis, but also because databases have several different types of code that have different conventions and considerations. There is DML (Data Manipulation Language), DDL (Data Definition Language), DCL (Data Control Language) and TCL (Transaction Control Language). They each require rather different analysis.
William goes on to include a set of good resources, though I think database code analysis, like database testing, is a difficult job in an under-served area.
Hearing this is one of those things that really bugs me.
And it’s not actually about stored procedures, it’s about the mindset that sits there.
I hear this sentiment in environments where there are multiple developers. Where they’re using source control for all their application code. Because, you know, they want to make sure they have a history of changes, and they want to make sure two developers don’t change the same piece of code, maybe they even want to automate builds, all those good things.
But checking out code and needing it to pass all those tests is a pain. So if there’s some logic that can be put in a stored procedure, then that logic can be maintained outside the annoying rigmarole of source control. I guess this is appealing because developers are supposed to be creative types, and should fight against the repression, fight against ‘the man’, fight against control.
When I come across this mindset, I worry a lot.
Read on for Rob’s set of worries, and hie thee to the source control repository. It really doesn’t matter which source control product you use (ideally, the same one that developers use for their app code), just as long as it’s in source control.
The aim of this blog post is twofold, it is to explain how:
- A “Self building pipeline” for the deployment of a SQL Server Data Tools project can be implemented using open source tools
- A build pipeline can be augmented using PowerShell
What You Will Need
Jenkins automation server
SQL Server 2016 (any edition will suffice)
Visual Studio 2015 community edition
A windows server, physical or virtual to install all of the above on, I will be using Windows Server 2012 R2 as the operating system
Automated integration via CI is extremely helpful, and Chris makes it look easy in this post.