Carly Meichen

30 April 2019

4 steps to laying the foundations for standardized database development

Updated June 2020

In the increasingly demanding world of software delivery, IT teams are feeling the pressure to deliver value to customers – either internally to the business, or external users – quicker than ever. This is often at odds with the day-to-day demands associated with maintaining legacy code, fixing and reworking issues, and trying to collaborate effectively with team members who may or may not be located in the same office, building, or even country.

Then there’s the database, which is still perceived as a bottleneck in the development process for three reasons.

1. The shape of the IT team is changing

In order to meet business demands, teams are increasingly distributed across multiple locations, time zones or working patterns. The Future Workforce Report 2019 for example, states that remote working is the new normal, and goes on to predict that by 2028, 73% of all departments will have remote workers, with 33% of full-time employees working remotely. This matches similar comments we frequently hear from our own customers. This year (2020), more and more organizations were also encouraged to respond and adapt quickly to remote working where possible.

Without standardized development systems and processes in place, this presents a number of challenges. Among teams, effective collaboration is nigh on impossible, and time and space to innovate is difficult to orchestrate around everyday pressures.

From a team manager’s perspective, new starters are unable to come in and pick up where the last person left off. Projects are also slow off the line and time is typically spent debating the fundamentals like version control setup and consistent naming conventions, which could already be in place to help teams hit the ground running and deliver value sooner. Not only that, a general lack of visibility of team progress makes everyone’s life harder.

2. You’re expected to deliver more with less

To add to this frustration, IT teams are under pressure to deliver more with less resource. They’re running just to stand still, spending time repeating work unnecessarily and having to make risky hot fixes. As a result, skilled staff are wasting time on tedious, manual rework, rather than more enjoyable added-value development. Business are losing out too, with new features that can make them more competitive taking longer to introduce.

3. Database development is lagging behind

For DBAs, having a centralized role supporting multiple teams means they often feel the pressure as they try to deal with a range of changes and issues without consistent structures or formats.

Then there’s the proverbial elephant in the room affecting businesses the world over: concerns about data privacy are blocking developers from accessing realistic data in development and test environments. This leads to performance issues further down the line, thus perpetuating the need for avoidable rework. Without version control and a solid audit trail, team leads also have a lack of visibility over who made what changes and when.

With too many manual steps leading to error-prone development, and conflicting changes that need to be troubleshooted and reworked, teams are unable to respond to business needs fast enough. Ultimately, without a unified process the database is slowing down software delivery and deployments are often risky, causing tension between application and database teams.

There is another way

If this is sounding highly relatable, where do you start? We often hear from our customers: “We’re trying to achieve a digital transformation”, and “We want database automation in line with our application”. For sure, the holy grail may be automated deployments and full compliant database DevOps to enable the deployment of application and database changes in a frequent, reliable and repeatable way. However, getting to that goal requires taking smaller steps first.

If DevOps is a completely new concept for your organization, you may find pushing for full automation right away creates a culture shock that can fail at the first hurdle. In the 2020 State of Database DevOps Report, 64% of respondents said the speed of delivery of database changes, freeing up developers’ time for value added work, and reducing the risk of losing data during deployments were the top drivers for automating the delivery of database changes. Laying the foundations with first-class, standardized development practices, these benefits can be reaped sooner than you think.

Let’s take a look at four key best practices to help you work more efficiently.

Adopt version control

The 2020 State of Database DevOps Report revealed that 78% of application developers are also now responsible for database development. This makes standardizing the way database code is written and version-controlled important in order to reduce errors, with everyone in the team working in the same way from a single source of truth. It also provides an audit trail of the changes made, enabling compliance to be demonstrated, and provides the foundation for automated Continuous Integration and Continuous Delivery processes in the future.

In this article, Mary Robbins provides six reasons to version control your database.

Introduce dedicated development environments

With version control in place, extend the process by equipping development teams with realistic, sanitized copies of production in their own dedicated environment. This will avoid unpredictable performance problems further down the line because developers are working on realistic datasets, while minimizing the risk of overwriting each other’s changes. With the processes in place to provide developers with the up-to-date, compliant environments they need, they can focus on value-added development.

In this article, James Murtagh explains how to ease the transition from shared to dedicated database development.

Standardize coding styles

Next, supply developers with tools to considerably speed up writing code. Ensuring a consistent and uniform coding standard across and within teams allows for potential issues and errors to be caught upfront before they’re promoted up the pipeline, particularly if the tools include static code analysis.

This empowers teams to deliver quality code and frees up their time to value added work. The benefit of consistent, readable code also makes it far easier to collaborate, review each other’s work, onboard new team members to a project, and quickly spot where issues lie.

Adopt unit testing for the database

Finally, unit testing is important as part of a standardized reliable process because it aids developers to ‘shift left’. It introduces a known, quantifiable, and repeatable practice to catch errors in code, and ensures that all developers are able to read how their code will be evaluated and more importantly understand, code and contribute to company-wide testing best practice moving forward. Having an automated readable output at the testing stage makes catching and fixes issues much easier.

It’s also important that once you reach the stage of automating tests you’re not trying to combine multiple disparate methodologies and approaches to what is ultimately the same problem, so taking a step back to review and put processes in place upfront will pay dividends.

Summary

By adopting the industry-standard tools for version control, provisioning and coding, teams will find it easier to collaborate, free up their time to innovate, add value and focus on more enjoyable work. For the business, the foundations for automation and compliant database DevOps are being laid, while speeding up and simplifying team-based database development.

Ready to discuss how to standardize your development processes? Take a look at our solution pages or get in touch to discuss your business challenges and requirements.