DevOps: Remove the space. Make better products.

The route to DevOps is a cultural shift which is integral to the success of any software business.

You might not do it all right now, and that’s fine.
You might do some parts well, and some parts not so well. That’s fine too.

Extending DevOps is a journey, with the end goal being connecting the same principles & practices you do with your development teams to the rest of your business, ultimately creating a scalable workflow, manageable team cadence and by becoming more responsive and agile than before.

Let’s start by looking at what DevOps might look like to a typical developer:

  • Utilising version control & issue tracking
  • Employing software-driven IaaS management
  • Continuous integration
  • Automated deployments

You’re probably asking how we roll the above out to non-technical teams, however, the principles in each of the practices above can be implemented around existing frameworks & systems in use by project teams and can augment support processes and even help boost your sales function.

All too often, development, product, and operations teams work in silos, with too little discussion around the important stuff;

  • Are we focusing our energy on the right things?
  • Is the solution to this problem adding value for other customers?
  • Where is our product going?

DevOps is about inclusion, and we must fight spell check’s urge to put a space in between the two words comprising the portmanteau!



So we know roughly what DevOps looks like from a software team, but how do we implement it throughout the company?

I firmly believe it comes from the top, and by introducing better communication channels between historically disconnected teams.

Ops, Meet Dev

The main benefit of getting your operations team on board with DevOps is cohesion. It’s probably fair to say that your operations team doesn’t want to be looking at JIRA boards all day, just as your development team doesn’t need to know each and every thought. However, agreeing on a common toolset and having buy-in to ensure this is used correctly is a great way to ensure that both teams work together to ensure the delivery of relevant and high-quality software.

The result of doing this is that it breaks down the traditional barriers and ‘God complex’ which sometimes breeds in development teams by bringing everyone, from the product team to the support people into the product design, development and QA process.

At Layer Systems, we use Aha! as the conduit which brings the teams together.

Dev, Meet Ops

So you’ve got your systems (close to) perfect, what next?

Speedy code shipments and quick feedback loops are what most developers working in a team want: their work gets from their workstations to users’ screens much faster and continuous delivery enables faster iteration and product improvement.

If you’re just getting around to implementing DevOps, why not set up a few key metrics to check if it’s working for you as you transition:

  • How quickly does it move from ‘done’ to release
  • How often are you deploying to production
  • How much manual intervention does a deployment need

In Summary

Start small with the cultural shift.

Implement tried and tested processes within your development team, and then look for buy-in from your operations team and repeat.

Then you’ll be one.

Art of Working in Wood

Strathclyde University‘s Centre for Lifelong Learning has an amazing workshop called FABLAB, which is home to loads of high-spec tools & equipment. Graham Murdoch runs daytime and evening classes here. I did one this spring and built a dog lamp, pictured below. You should check out the course details here and register for the next session!

Taming SQL Server Transaction Logs

Ensuring your log files are in good shape when using SQL Server with AlwaysOn Availability Groups is essential and should be an integral part of your database deployment & management strategy. Since AlwaysOn requires full recovery model to be enabled prior to configuration, your logs must be backed up regularly in addition to the database itself.

If you’re reading this, it’s more than likely you’re trying to find an easy way to clear down your growing log files. I’d recommend taking a little time to think about why it’s happening in the first place before you do anything else. Perhaps your logs aren’t backing up properly, your preferred backup replica is configured incorrectly or one of your secondary replicas is in error or playing up, Whatever the reason, diagnose it before going any further using the steps below.

The best place to start is by examining the state of your transaction log files in order to determine the reason that your logs are filling up and space isn’t being cleared. You can do this by issuing dbcc loginfo against the database with issues then cross reference the reason ID(s) against Microsoft’s Factors That Can Delay Log Truncation list (from sys.databases).

So you’re not using HADR?

If you haven’t implemented a high availability solution such as AlwaysOn or database mirroring, a temporary fix (if your RPO allows) is to change your data recovery model to Simple in order to avoid backing up transaction logs at all. This isn’t recommended for any production environment where data loss is a concern. Again, do not attempt to change this if your database is part of an AlwaysOn Availability Group.

And if you are?

OK, so we’ve already established that why our logs aren’t backing up by running dbcc loginfo. Let’s run the following in SSMS against all the databases causing you problems so we know what we’re working with prior to attempting to resolve the issue

USE [yourDatabase]

If your logs are massive and growing *and* you’re taking regular backups, it’s worth checking that the SQL Server instance you’re taking backups on is set as the preferred backup replica in SQL Server. An incorrect setting in here can often delay the truncation of transaction logs.

Let’s free up some space

Ok, now we know which databases (and logs) are causing the problems, we can start to try and shrink them. If the results of your dbcc loginfo show that a replication issue is a potential problem, check the health of your availability group via the dashboard to ensure your replicas are in good shape. If not, you could remove the offending servers from the group until you’ve resolved the issue.

Next, take a backup of your log files. If space isn’t a concern, back these up to a physical drive. If you’re having issues with space (which is more than likely if you’re reading this), dump it to NULL. Please do this at your own risk as NUL is a special place in the file system. It’s the nul device, the outside bin or black hole of the file system.

BACKUP LOG [yourDatabase] TO DISK=‘NUL:’

Next, if required, let’s start to shrink your files. Again, run these at your own risk and ensure you have a full backup in place beforehand:


Finally, get your backups back to normal and then go and explore what was *actually* causing your issue in the first place.

A good place to start is to ensure your backup solution is taking regular full backups, as well as frequent differentials & transaction logs.

Good luck!