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 2018 states: 55% of hiring managers say remote working is more common than 3 years ago, and 53% use flexible workers. This matches similar comments we frequently hear from our own customers.
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 2019 State of Database DevOps Report, 60% 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 2019 State of Database DevOps Report revealed that 77% 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.
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.
Also in Blog
As I’m sure you’ve already heard, Redgate recently celebrated 20 years of making ingeniously simple software, but did you know that we’ve also been supporting the Microsoft Data Platform communi...
Also in DevOps
At Redgate, we research DevOps, write articles, whitepapers and other content about DevOps, and talk a lot about DevOps. We actively encourage our customers to introduce database DevOps too, using our...
Also in Database development
A while ago, James King of Redgate spoke to Tony Madonna, the Microsoft Platform Lead and SQL Enterprise Architect at BMW about the growing SQL Server estate at the car manufacturer, and how and why m...