DevOps: To branch or not to branch

One of the discussions that comes up from time to time when working with DevOps is branching strategy.

One of the main features of Git that’s often claimed is that it’s so good at branching and merging. And indeed, it’s pretty good at that. But the bigger question is whether lots of branching is desirable in the first place.

One argument says that if you are using branches (let’s say to build features), that you really aren’t doing Continuous Integration (CI). The downside of being features in separate branches is that at some point, you’ll have to merge the code back in, and there’s probably going to be nothing automated about that. One software house that I’ve been mentoring in has a very large number of active live branches.

Each time a merge to a central trunk (ie: master branch) is attempted, it’s beyond painful, often takes months, and introduces enormous numbers of bugs that need to be fixed. If you then combine that scenario with a lack of decent testing, you have a problem. Merging becomes really, really scary.

Image by Priscilla Du Preez
Image by Priscilla Du Preez

There is nothing agile or continuous about that.

The alternative approach is to always work in the master branch. While you can end up colliding with what other people are doing, at least you deal with that right then and there. You can end either with a frustrating set of collisions so that you’re endlessly working with an unstable base, but at least you know about it straight away.

A bigger issue is that it’s easy to accidentally release unreleased features into the wild, or at least parts of them. Feature flags are often used to try to hide this but that can go wrong too.

So in the end, to branch or not to branch? My take on it is that branches are fine if they are letting you try something out in a scratchpad area, and when they are really short-lived. But long term branches aren’t something that I’m keen to see.

DevOps: Scripting SQL Server objects and data from the command line

The other day I posted a shortcut about how to use SQL Server Management Studio (SSMS) to generate INSERT statements for data.

In one of the comments, Tom Corrigan asked if there was a way to do that from the command line.

The answer is yes. Apart from a variety of 3rd party tools, in May last year, Microsoft released tools to do just that.

The new tool is mssql-scripter and you’ll find an intro to it here:

https://blogs.technet.microsoft.com/dataplatforminsider/2017/05/17/try-new-sql-server-command-line-tools-to-generate-t-sql-scripts-and-monitor-dynamic-management-views/

They describe it as “the multiplatform command line equivalent of the widely used Generate Scripts Wizard experience in SSMS”.

Importantly, note the fact that it’s multiplatform. It’s built in python and works on Linux, macOS, and Windows and can create both DDL and DML scripts that target SQL Server, and that also includes Azure SQL Database and Azure SQL Data Warehouse.

You choose where the output goes. Normally you’ll send it to .sql files but like any other Unix style utility, you can pipe its stdout to other commands.

The source code is up at github here:

https://github.com/Microsoft/mssql-scripter

I love the fact that Microsoft teams are now putting source code like this up on github: continuing evidence of a “new Microsoft”.

That means that you can:

  • Use it as a great learning resource
  • And if you’re keen, submit pull requests to improve it

So to generate INSERT statements, you can use it like this:

mssql-scripter -S somesqlserver -d WideWorldImporters -U someuser -P somepassword –include-objects Customers –data-only

Note that it would all be on a single line.

Opinion: Which SQL Server columns should be nullable #2: Avoid placeholder values

In my previous opinion post, I was discussing why magic values where a problem. They are often added by developers when they are trying to avoid having any NULL data in a database.

While discussing this, I think it’s worth also highlighting the overall dangers of placeholder values. These are values that aren’t magic values but are ones that are intended to be replaced at a later time.

If you use any of these, you need to have a solid process in place to:

  • Make them consistent and easily identifiable
  • Replace them in any database that’s heading towards production
  • Avoid them like crazy in production databases (and if you can’t do that, have a great process for finding any that leak out)

Here are some examples of what I’m talking about:

This one is quite nasty because it really has nothing to make it stand out from the containing text.

The main image above with the TV show is a more obvious one (or you’d hope so). No doubt it’s a little harder for them to detect the use of that one but it can’t be that hard, or they need to use another type of image that doesn’t require human detection.

One of my favorites is where people have used text generators, but then forgotten to replace the text. Here’s an example on a wine bottle:

This is the classic Lorem Ipsum text.

The problem here is that they wanted something that really made the mock-up of the bottle look like the real thing. Unfortunately, it really did. I am surprised that whoever printed the labels didn’t notice it though.

Ideally, if you have a good DevOps process, you might need to have a testing step that checks for the presence of any placeholder values before any data is published.

Before I leave this topic, for a little fun, Shopify published a link to some cute lorem ipsum style generators.

https://www.shopify.com.au/partners/blog/79940998-15-funny-lorem-ipsum-generators-to-shake-up-your-design-mockups

They did fortunately include my oldest favorite: Bacon Ipsum.

Next week, back to how NULL does/doesn’t fit with database design.

 

 

DevOps: What is a managed service?

Some time back, I decided to use a WordPress host for my blog because the time for me at sqlblog.com was coming to an end, community service was on its last legs, and WordPress seemed the obvious platform for a blog. Fellow MVP Adam Machanic made it really easy for me to migrate to a WordPress site with a tool that he had created.

Along with another site, I put them onto BlueHost and had reasonable hopes for them. However, a few weeks back I found that my blog had simply stopped working. I couldn’t even log into the control panel to work out what was wrong.

The support chat that they offer is beyond slow. Every time I’ve used it, it takes ages to have anyone connect, and then while you’re talking to them, it’s like talking to someone on Valium. There are really long delays between responses. I can only assume that they are trying to talk to lots of people at once.

In the end, they told me that I’d run out of disk space. For the life of me, I couldn’t work out how that was possible, given the amount of space purchased. Eventually it became obvious that the thing occupying all the space were some backups that I didn’t configure, that were being performed into a folder that I couldn’t see unless I could log on, and with no reasonable cleanup policy to get rid of old backups ie: You could argue that it was designed to fail.

The amazing part was when I asked them to just delete the old backups, because I was unable to, they told me they’d arrange it but it could take up to another day or so to do that. No-one who had permission to delete them was at work.

That’s when I decided that I need to move away from this service, even though I’d prepaid it for quite a while into the future. We’d moved the other website already anyway, and so I thought I’d look for a managed hosting service for WordPress.

Many people mentioned they had good outcomes with InMotion hosting. When I checked it out, I saw they had “WordPress-Optimized Managed Web Hosting”. I looked at the list of features and was very, very impressed with what they offered and eventually signed up.

One of the first things the guy activating my account explained though, is that I need to get involved in the backups. Turns out they do a backup every 24 to 36 hours, over the top of the previous backup. They only keep a single backup for me.

I pointed out that a backup that’s done over the top of a previous backup really isn’t a backup at all. 

The guy told me that to use their service, I needed to make sure I kept local copies regularly, in case something went wrong. I asked him “if I need to do my own backups, what exactly about their service is managed?” He couldn’t answer me and said he needed to ask someone else in the company.

Surely keeping reliable backups of the site (and me not having to do it) is the number #1 thing that a managed service should provide.

Sadly, I’ve had to cancel the service before I even got started with it. It’s a real pity because there’s much to like about their offerings, and they are responsive.

I’ve never been a fan of GoDaddy (had some beyond-horrid experiences dealing with them in the past), but as a comparison, it’s informative to look at what they advertise for backups in their managed service. They say they keep daily backups for 30 days, and have a one-click restore process to go back to any of them.

Microsoft does similar things with Azure SQL Database. I don’t worry about the backups, they keep many, and at any point I can just roll a database back to a previous point within the last few weeks.

That’s more what I’d expect in a “managed” service.

While it’s easy to call a service “managed”, here’s a hint: if I need to be involved with the core admin functions like backup, it’s not a managed service.

 

 

DevOps: Human testing is still critical – and make sure they can spell

I’ve spent a lot of time lately working with automated testing systems.

Unit tests are great for checking blocks of code, etc. but integration tests and functionality tests are critical to projects. An area that is still tricky though is UI testing. There are some really good tools for this.

Selenium has been very popular and works well if you access it programmatically. There are good framework libraries for .NET and we’ve been using those. Selenium also had a pretty good IDE that could be used for recording but it’s pretty much adrift now as it was based on an older version of Firefox and doesn’t work on the latest versions. You could install it on an older version for testing but those versions aren’t safe to use so the recommendation is to avoid it. Working with it programmatically is not that hard though.

This article shows a number of alternatives: https://www.guru99.com/selenium-alternatives.html

I’ve tried quite a few now but had pretty mixed results, so this area is still evolving. I had fairly good results with Katalon Studio but ended up quite frustrated with trying to use its recorder. So I ended up back to coding Selenium directly.

One thing that’s been very clear to me though, is that no matter how good all this automated UI testing is though, you still need humans to do it as well. You can see examples above of basic UI issues.

Here’s an example of a UI logic error:

It’s also very clear that the humans that do this need to be able to spell.

No matter how good looking your application is, if it’s full of spelling errors typos, or graphical errors, it won’t look professional.

DevOps: Keep moving forward not backwards when deploying to production

I was asked a curious question the other day: “Are all changes made to production systems actually deployments?”

I wish the answer was yes, but unfortunately patches do get applied directly to production systems without going through standard deployment processes.

Everyone understands the scenario. Code has been deployed using the normal processes, then someone has something that simply must be fixed urgently in the productions systems. At that point, you have two choices:

  • The traditional choice is to urgently patch the production server, then reapply those changes back into the development process.
  • The ideal DevOps approach is that an urgent patch is made in earlier environments then deployed through the normal processes.

The reason that people opt for the traditional choice above is that going back through the processes simply takes too long in most organizations. The problem with this option is that there’s no guarantee that the change that was made in production will be reapplied the same way when it goes back into the normal processes. Worse, it might not be applied at all. Even worse, if there are multiple production servers, it might be applied differently to each of those as well.

Image by Alice Achterhof

Then you have a real mess to deal with. Deployments start to break, and because they are then painful, they become less frequent and more risky, and then they break even more. It’s a horrible cycle that you can easily get into.

The aim when working with DevOps is to streamline the process for doing this to the point where you won’t hesitate to have it go through the normal deployment processes. You urgently patch and deploy the patch instead.

DevOps: SQL Server and Unit Test Challenges

I had a previous life as a developer and ran a software-development house. Even then, I was very focussed on data. I don’t think I’ve ever had a BD (before data) period. I see almost everything I’ve ever worked on in data-related terms, so perhaps it’s the time before I focussed on data.

But what this does mean is that whenever I get together with other data-related people, I’m one of the people who is asking why things that are taken for granted in the developer community, aren’t present in SQL Server and its T-SQL language.

Testing is one of these challenges. I’ve had old wise colleagues in the past who see this simply:

It’s pointless to write code that you can’t test

And yet, T-SQL development is still one of the areas where that’s a challenge. Over the years, I’ve had many discussions with SQL Server product team members about this, and still haven’t been persuasive enough to convince them to do something about it.

I should note at this point though, that if you’re someone who sees the database as just a storage for your objects, that no code should exist in the database at all, and that the performance you’re currently seeing is good enough, then read no further.

But I currently live in a world where performance matters and many operations need to be done as close to the data as possible, with as little data movement as possible.

If you are developing in T-SQL today though, writing unit tests and test harnesses is just way more challenging than it should be. In many cases, you simply can’t do it in any practical way, at least not within T-SQL. There have been some great attempts like TSQLUnit (https://sourceforge.net/projects/tsqlunit/), and tSQLt (http://tsqlt.org/) but these aren’t really where I want to be. It’s not for lack of trying, but it’s for a lack of support within the product itself.

A simple example might help.

I can write code in T-SQL to trap and handle errors, including system errors (ie: those with error numbers less than 50,000). But if I want to test that error handling, I’m fresh out of luck. The “normal” way to do that in high-level languages is to write code to just throw that error and check what happens. But the product group have decided that we’re not allowed to raise system errors.

When I’ve discussed this with them, I get responses like “ah but then we’d get errors reported and we’d have no idea where they came from”. I get that they’re thinking from a conservative product support point of view, but that sort of thing can be handled. There would be a way to handle this if there was a desire to do so. And what I’ve never understood is the lack of interest in doing so. Product group members are, by and large, developers whose lives must take testing as part of their own routine.

Error handling is just one example issue though.

So we’re left with two options really:

  • Spend our time asking the product group for changes to support better quality development in T-SQL
  • Wrap all our unit tests in other languages, accept that we just can’t test some things, and deal with language limitations.

As we move into a DevOps-centric world, this is going to be more of an issue. I’d love to see us pushing for the first option and having the expectation that people developing with T-SQL should have access to similar developer-focused tooling to those building SQL Server itself.

DevOps: Avoiding SQL Server Clone databases growing way too large

I’ve recently been making use of SQL Clone from Redgate, at various client sites. I have to say that I really like it.

The basic concept is that you take an existing SQL Server database, you create an “image” from it, then you create database clones from that image.

Under the covers, it’s basically a differencing technology. The initial image is like an initial set of database files, and each clone is then files that are differenced from that. That makes it very easy to spin up clones, and to break them down again. While this isn’t really suitable for much in the way of performance or load testing, as everyone is sharing the same base, it’s perfect for general development.

It’s also a really good fit for use with source control systems like Git that developers endlessly create branches in. You can just create a clone for use with each branch, and avoid developers trampling on top of each other all the time. Each developer gets to have separate databases (or even multiple databases) and gets to test on full data volumes, without all the storage space that would otherwise be required.

What I have run into lately though, is a site where all of the clone databases were getting bigger and bigger constantly. Instead of being 40 or 50 MB as they started out, each was now taking hundreds of gigabytes.

That was pretty easy to track down, and it was caused by routine database maintenance tasks that the customer was scheduling. In particular, they were regularly rebuilding the indexes in the database. In a clone database that’s based on differencing technology, that’s not going to make sense at all. Rebuilding 200GB of tables or indexes could easily end up with a 200GB clone fine. And if you do that to all your clones, well you can see the problem.

What is needed is to avoid performing index maintenance on the clone databases. Given that to SQL Server, they just look like any other database, I’d suggest having a naming scheme for the clones, to make it obvious which they are, to exclude them from these operations.

DevOps: Should migration-based deployments use idempotent scripts?

In my last DevOps-related post, I discussed some of the issues that arise when using migration-based deployments.

Migration-based deployments are based on a series of T-SQL scripts that apply changes to your database from its current state to a desired final state.

One of the questions that arises though, is whether or not these T-SQL scripts should be idempotent ie:

Should the script be written so that you get the same outcome if you run the scripts multiple times?

Creating T-SQL scripts that you can reliably run more than once isn’t easy. It’s not required for migration-based deployments if all goes well, it might make them more reliable, and/or make them more useful when errors occur during deployment. However, achieving that isn’t easy.

In essence, creating scripts like this means that instead of writing code like this:

you write code like this:

But what would happen if the table is there but different?

Sometimes it’s also messier than you’d hope. For example, CREATE SCHEMA has to be the first statement in a batch. You can’t write:

Instead, you need to write something like:

And apart from now losing help from Intellisense, etc. within the script items, this sort of thing just gets harder and harder.

My experience is that apart from situations that are fairly trivial, creating seriously idempotent scripts is much, much harder than it looks, and it’s far too easy to create scripts that can still end up with different end states.

I think you are far better off validating the schema before running the migration, and if failure occurs, recover and re-run whenever possible.

 

 

DevOps: Dealing with issues in migration-based deployment of databases

In an earlier post, I described the difference between state-based deployments and migration-based deployments. What I want to talk about today are two of the main issues that can arise in a migration-based deployment and what to do about one of them.

When you are using a migration-based deployment technique, you are storing all the scripts that take a database from its current state to the desired final state. While tools like Ready Roll make this is a relatively easy way to perform migrations, it suffers from a few key problems:

Performance

When you are applying a series of steps to make all the required changes to a database, you may end up taking much longer than a move directly from the current state to the final state would involve. For example, you might add a new index, then later decide to add another column to it. Clearly it would be faster to just create the final index, rather than to create the index then modify it.

I often see deployments where indexes are applied, removed, reapplied, tables added, then removed again, etc. This isn’t a big problem for small databases but can be a major issue for larger databases.

While this is a real issue, it’s one that doesn’t have a simple answer when you are using migration-based deployments. It’s not one that I’m going to discuss further today. Let’s talk about another issue that you can do something about.

Drift

If you have multiple production servers, then servers in other environments (like UAT, Development, Test, etc.), in a perfect world, the schemas of the databases in each of these environments would be identical. Often though, that’s not what happens.

If an urgent production fix is required, someone might make a change directly on a production server. Worse, they might apply the same change differently on each of the production servers. Then they might forget to apply the same change (or apply it differently) in other environments. No matter what the cause, the schemas have drifted.

Now if you create migration scripts in the development environment, and even test them in a test environment, those same scripts might break when applied to the production servers because the scripts are dependent on the schemas being the same.

To work around this issue, your deployment process needs to start with schema comparisons, using either Visual Studio‘s schema compare, or a tool like Red-Gate’s SQL Compare.

You might not be able to get tools like this into the production environment, but generally, you should be able to script the database(s) in the production environment (and other environments), load the scripts in a test environment, and run the comparisons there.

If they aren’t in sync, you need to fix that first.

Once you know that you schemas are in sync, you can proceed with a migration-based deployment with more confidence.