DEVOPSdigest

Everyone understands the importance of code quality for applications, particularly when DevOps results in releases becoming faster and faster, reducing the room for error. The same issues increasingly apply to databases, which are a vital part of DevOps workflows. Fail to integrate the database into DevOps and you'll face bottlenecks that slow down your processes and undermine your efforts.

Obviously DevOps has to combine speed and quality. However, with larger and larger teams delivering more and more releases under ever-tighter timescales, ensuring consistency and code quality can be an issue.

This is particularly true when you have mixed teams combining both application and database developers, who have different backgrounds, skills and ways of coding. Or, increasingly, where application developers are expected to update the database as well as the application.

How can you ensure consistency and quality, and avoid the database being a drag on development? The key lies in looking for the same kind of productivity tool that application developers expect to help them write code faster, more accurately, while encouraging collaboration.

There are three areas in particular that companies should look to embrace:

1. Apply team styles

One of the biggest challenges for any developer coming to a new project with an unfamiliar codebase is getting to grips with the way the code is written and formatted. Just as application developers with different backgrounds will write code in slightly different ways, the same applies to database code such as T-SQL, used in SQL Server.

While the code will still do its job, trying to manage multiple writing styles adds to the overhead, particularly when it comes to testing and maintenance or if a developer has left, leaving someone else to puzzle over their work.

At the same time, mandating that everyone writes in a certain way is unrealistic — it will cause ill-feeling, add to training time and slow down coding. Instead, look at creating team styles that you can share across the organization, and adopt tools that let you apply them to code after it has been written.

That means developers can write in their own style and then see their work automatically switched to the house style, giving the perfect balance between what individuals and teams need to be more productive.

2. Share reusable code snippets

As with general software development, writing database code often involves repetition, with developers needing to achieve the same thing, multiple times. Rather than reinventing the wheel and making developers write code from scratch, use reusable code snippets for common routines that can be shared among the team.

This not only reduces the time to write new code, but also significantly lowers the risk of syntax errors sneaking in, particularly if you have a mixed team when it comes to experience and knowledge.

The result is that code is easier to understand, faster to test and ultimately quicker to deploy, ensuring DevOps requirements are met.

3. Expect real-time code analysis

Any productivity tool used for writing T-SQL will provide auto-complete suggestions as the code is written, reducing errors and speeding up coding. That's no longer enough. DevOps is all about shifting left, identifying issues earlier in the development process and fixing them before they become problems.

So look for a tool that also highlights code problems and pitfalls in code, the moment it is typed, and provides clear explanations, suggestions to improve the code, and links to further information. That way, code smells are avoided, and the quality of code is consistent, even among relatively inexperienced developers.

Every organization will have its own standards and ways of working, so ensure you choose a tool that lets you customize the analysis rules and how they are applied, so they fit in with your DevOps workflows.

Data is a vital part of every business, meaning databases are at the heart of successful DevOps. With more than 75% of organizations now having developers in their teams who work across both applications and databases, you need to ensure code quality is continually enforced. That's why you should extend code analysis to cover your database as well as your applications if you want to drive DevOps forward.