22 June 2018
22 June 2018

SQL Code Analysis from a PowerShell Deployment Script

Guest post

This is a guest post from Phil Factor. Phil Factor (real name withheld to protect the guilty), aka Database Mole, has 30 years of experience with database-intensive applications.

Despite having once been shouted at by a furious Bill Gates at an exhibition in the early 1980s, he has remained resolutely anonymous throughout his career.

He is a regular contributor to Simple Talk and SQLServerCentral.

Database code analysis becomes more important as the team doing the database development gets bigger and more diverse in skills. Hard-working database developers sometimes check-in ‘temporary’ development code, by mistake, so it is always good to have a way of flagging up SQL Code issues and ‘smells’ that are agreed to be incompatible with ‘production’ standards.

Database Developers like to agree and share a common set of styles and conventions, so that they can work easily on all parts of the database code. Where the developers need to work across applications, rather than just on the database, these pre-release checks on the source become even more important, because these checks should indicate where code review might be helpful. SQL Code Guard can work with either a database, or the source code.

We all have different views of what constitutes best-practice, so SQL Code Guard allows the team full control over what gets checked, and what is ignored. The most important aspect of checking on code is to ensure consistency. The team need to be able to share settings easily and change them when necessary. Code analysis settings are best kept in source control with the version.

Automating static code analysis on a database

SQL Code Guard’s static code analysis rules are now built-in to SQL Prompt so that developers can usually avoid checking in suspect code. The command-line version of SQL Code Guard can read the code analysis settings from SQL Prompt, and can be used simply in PowerShell. This means that SQL Change Automation, and any other PowerShell-based process, can be adapted to run automated SQL code analysis.

Delivery teams can create and share a configuration file, defining which rules to include or exclude, for development and build tests, so that the report that is generated reflects, consistently, the current development standards.

The current command-line version of SQL Code Guard can be downloaded from the Redgate site as a ZIP file, and should be installed in a directory, with all the files together. As long as the command-line version is fully-referenced by its path, it should work fine.

Listing 1 shows a simple way of using SQL Code Guard in PowerShell to check a live database. You will, of course, need to fill in the correct values of the parameters. Be careful, also, to ensure that your Windows user has rights to create a file at the outfile destination.

Listing 1

The output of the program has interesting information such as the number of code-smells being searched, but the only word we are looking for in this example is ”Error”. There is also a log file that can be stored with the documentation of the build.

I’ll show in a moment how to view the resulting XML file, containing the code analysis findings.

Automating static code analysis on source code

You can check the code in any SQL file in any database build script (.sql file), or directory with .sql files in it. Here is a typical format of source control directory, but any directory structure is OK, as it will be searched recursively for any .sql file.

The PowerShell code is even simpler, as there are fewer parameters.

Listing 2

Using a code analysis configuration file from SQL Prompt

If you are using the code analysis feature of SQL Prompt, you can use it to save the code analysis rules settings into a configuration file.

Within SSMS, select Manage Code Analysis rules from the SQL Prompt menu, configure which rules you want enabled or disabled, and then save your settings by clicking Save as…, changing the file location to a shared folder and clicking Save. You can also save the configuration file from the Code Guard add-in for Visual Studio. The UI saves it in %APPDATA%\SqlCodeGuard.Addin\settingsv3.xml.

Listing 3 shows the PowerShell to view the configuration file to get a list of what is being checked and what isn’t.

Listing 3

You use your XML configuration file with either a database or source code.

Listing 4

Viewing the XML file

So far so good, but the result is an XML file. There are plenty of ways of viewing it once you can get it into a table. Listing 5 shows one way to do that.

Listing 5

Which will give something like this:

As this is scripted, there are plenty of ways of making the reporting side as elaborate as you wish, even sending email reports, the destination of which is based on the name of the object. You can even use PowerShell to attach the relevant report to the SQL script file as a block comment if you have a consistent file-naming convention that is based on the name of the object.

The simplest possibility is to convert the XML file to HTML for a website or email-based report. This can be done relatively simply in PowerShell by using the .NET XSL Translator. The XSLT file is created on the fly, so it can be parameterized to give additional information such as the server being tested or the date.

Listing 6

This will give an HTML-based report like this:

Conclusions

Currently, the command-line version of SQL Code Guard is free to use, subject to the license conditions. It provides a good way of checking the code of any SQL Server database development as part of a continuous delivery. It integrates with other Redgate products. It can, for example, use the code analysis checks, as determined by the development team using SQL Prompt. It is easy to use as part of a DevOps toolchain. More than anything, though, I like it because it is a great way of saving me from embarrassment!

Guest post

This is a guest post from Phil Factor. Phil Factor (real name withheld to protect the guilty), aka Database Mole, has 30 years of experience with database-intensive applications.

Despite having once been shouted at by a furious Bill Gates at an exhibition in the early 1980s, he has remained resolutely anonymous throughout his career.

He is a regular contributor to Simple Talk and SQLServerCentral.

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

You may also like

  • Article

    Staying In-sync with drift correction

    Getting everyone in a team behind a process change is hard. As a database developer, not only do you need to champion the new process within your own team, but you also need to extend the olive branch to your DBA to ensure everyone is on-board with the changes. This is where you may encounter

  • Event

    IP EXPO Nordic

    IP EXPO Nordic is the number 1 enterprise IT conference for the Nordic’s and it is bigger and better for 2018. This is the ideal conference for those looking to find out how the latest IT innovations can drive their business forward. The 2 days incorporates over 80 seminar sessions and over 120 exhibitors and covers

  • Article

    Using database replication with automated deployments

    For the SQL Change Automation team, it’s important that we take time out from development, occasionally, to explore some of the issues our customers face when automating database deployment. Following on from previous posts about cross-database and cross-server dependencies and production database drift, this article shares some of our thoughts about how to deal with database replication.

  • Article

    Baselining a SQL Change Automation project from an existing database

    Deploying schema changes to SQL Server databases can be tricky when you’d like to automate parts of your workflow. For instance, how do you go about version controlling your schema changes? In application development there are many tools you could use such as Git, or Subversion. However, there exists no obvious choice for SQL Server

  • University

    Take the SQL Change Automation course

    In this course, you’ll learn how to use SQL Change Automation to capture database changes in migration scripts that can be customized and used for deployments. This gives you full control over the deployment. You’ll also learn how to use these migration scripts as part of an automated CI/CD pipeline.

    If you’re interested in learning more about automating database changes with the state-based approach, then see the SQL Change Automation with SQL Source Control course.

  • Forums

    SQL Change Automation Forum

    Continuous integration and automated deployments for your SQL Server database