State of Devops

The State of
Database DevOps
Survey on DevOps adoption rates
among SQL Server Professionals
The State of Database DevOps Survey on DevOps adoption rates among SQL Server Professionals
Foreword
DevOps is an emerging model of product delivery and full lifecycle
management that emphasizes a holistic, end-to-end process. It seeks to
remove the silos between Development and Operations, and indeed all key
stakeholders in the application lifecycle. DevOps means people, process
and the right tools working together to make the product delivery lifecycle
faster and more predictable. DevOps is fundamentally changing the IT
landscape, and that change was long overdue.
When you look at statistics on project delivery you can see that most large Enterprise
IT departments are struggling to deliver – at best 25% of the IT spend is being wasted on
failed projects and rework and some estimates have that as high as 50% or more. When
you add to that the huge changes required across the organization to deal with digital
disruption and digital transformation it becomes obvious that something must change.
DevOps concepts such as Agile, Continuous Integration and Continuous Delivery mean
that new iterations are released faster and faster, and production software is improved
faster and faster, until the end-product is in a state of continuous improvement.
While DevOps clearly focusses on ‘Dev’ and ‘Ops’ it has often been asked where do
Databases fit in this model? Within the context of Continuous Delivery, databases have
often languished some way behind code deployments, and while the ability to deploy
changes to existing environments is now relatively common, supporting databases in
a truly elastic environment remains a major challenge for organizations.
Redgate set out to discover how much of a challenge the database presents by asking
1000 SQL Server professionals how many had adopted, or planned to adopt, DevOps
processes and tooling in their organization and how many had extended those practices to
the database. Their findings are presented in this report.
Tom Beavan, DevOpsGuys

Key Findings
Over 1000 SQL Server professionals participated in the survey, with

respondents coming from across the globe and representing a wide range
of job roles, company sizes and industries. Among the key findings are:
47% of respondents have already adopted DevOps practices across some or all of
their IT projects. 33% plan to adopt a DevOps approach within the next 2 years. Only
20% have no plans to start applying DevOps practices to their software delivery.
75% of respondents have developers in their team who work across both
applications and databases. But the greatest challenge with integrating database
changes into a DevOps process would still be synchronizing application and
database changes, and overcoming different approaches the two teams have
to development.
The greatest drawback identified with traditional siloed database development is

the increased risk of failed deployments or downtime when introducing changes.
This is closely followed by slow development and release cycles and the inability
to respond quickly to changing business requirements.
Increasing the speed of delivery of database changes and freeing developers up

to do more value added work are the key drivers for automating the delivery of
database changes.
Only one fifth of respondents are already applying DevOps practices like continuous
integration, automated testing or automated deployment to their databases.
Has your organization already adopted, or do you plan to adopt,

1
a DevOps approach across any of your IT projects?
12% 35% 33% 20%

already adopted across all already adopted across some plan to adopt across some or Not adopted and no plans to
projects projects all projects in the next 2 years adopt within the next 2 years
47% of respondents had already adopted a DevOps approach to some or all of their
Projects, demonstrating that DevOps is becoming more mainstream. A further 33%
plan to adopt during the next 2 years. Only 20% of respondents had no plans to adopt a
DevOps approach within their organization within the next two years.
Notably, rates of adoption appeared to increase with company size, reaching 59%
among companies with over 10,000 employees.
Across industry results varied, with the highest levels seen in IT Services and Retail
where more than 50% of respondents were using DevOps processes across some or
all of their projects. The Finance and Healthcare sectors were not far behind perhaps
demonstrating the important of process in highly regulated industries.
Unsurprisingly, lower levels of adoption were seen in the Manufacturing and

Government, Education and Non-Profit sectors, where less than 40% of respondents
had adopted any kind of DevOps practices. In these sectors, a higher number of
respondents, 27%, also thought it unlikely they would adopt this new way of working
within the next 2 years.
4
What was, or what would be, the main obstacle to implementing a

2
DevOps approach in your organization?
20% Lack of alignment between development and operations teams
9% Lack of support from executive leadership
21% Lack of appropriate skills in the team
17% Disruption to existing workflows/business
10% Lack of budget to invest in new tooling
17% Lack of awareness of benefits to the business
6% Other
The greatest obstacle to moving towards a DevOps ways of working overall was
considered to be a lack of appropriate skills in the team, followed by a lack of
alignment between Development and Operations teams.
The barriers were notably different between groups of respondents though. Those
who were planning to adopt DevOps practices sometime in the next two years seemed
most concerned about a lack of appropriate skills in the organization.
However, for those respondents who didn’t have any plans to move towards a DevOps
way of working, a lack of awareness of the business benefits of DevOps was cited as
the main obstacle, accounting for 35% of the responses. The second highest response,
from 15% of this group, was cited as a lack of budget to spend on new tooling.
This suggests that until they fully understand the potential return on investment,
organizations will simply not be willing to invest.
5
Which of these best describes how closely your developers and

3
your Database Administrators (DBAs) are integrated?
20% 38% 30% 12%

Great Good OK Poor
All work together effectively as teams collaborate together DBAs aren't really involved DBAs are completely siloed,
one team, using standardized with DBAs getting more and only work with unaware of what's happening in
processes and tools involved on an ad-hoc basis development when its time development and deploy database
when needed for a production deployment changes to production in isolation
The majority of respondents reported that their development team and DBAs are well
integrated, with 59% answering either ‘good’ or ‘great’ to the question about levels of
collaboration.
This figure went up to 71% among those who had already adopted a DevOps approach
to some or all of their projects. But with 5% of these groups reporting poor integration,
and 24% saying DBAs are only involved when it came to deployment, it seems some
teams still have a way to go before the database is fully embraced as part of the
DevOps pipeline.
More interesting perhaps is the fact that, among the respondents who have no plans
to adopt a DevOps approach at all, almost half of them already report good or great
working relationships between database development and operations teams. 22% of
them are already working effectively as one team using standardized processes, even
if they don’t consider themselves to be using DevOps methodologies.
6
Does your team include any developers that work across both
4
databases and applications?
25% Our team has dedicated

database developers
75% Our developers are responsible for both

database and application development
The overwhelming majority of teams contain developers who are responsible for
both application and database changes and this percentage changes little when
comparing responses between teams who had or hadn’t already adopted a DevOps
to their projects.
7
5 Who typically builds database deployment scripts?
60% Developers
35% DBAs
5% other
Who is responsible for the deployment of database changes

6
to production?
39% Developers
52% DBAs
9% other
When it comes to the building of database deployment scripts, overall the large
majority are built by developers with the responsibility resting with the DBA in only 35%
of organizations. The DBA is still responsible for deploying the scripts to production in
just over half of organizations.
The percentages shifted somewhat when filtering results for those who had adopted
DevOps already. In those organizations it is clear that developers have more operations
responsibilities, with a higher proportion of developers building database deployment
scripts (74%) and also making deployments of database changes to production (45%).
8
Which, if any, of these practices are Which, if any, of these practices are
7 already in place for your application 8 already in place for your database
development: development:
Automated provisioning 15% Automated provisioning 9%
Version control 81% Version control 58%
Continuous integration 39% Continuous integration 20%
Test automation 38% Test automation 19%
Automated deployment 33% Automated deployment 21%
Application performance monitoring 36% Server performance monitoring 50%
Issue tracking 64% None of the above 16%
Configuration management 36%
None of the above 6%
Use of source control is high, particularly as expected in application development with

81% of respondents versioning their code. The numbers who use database version
control are lower at 58% but still form the majority.
As expected these percentages rise among organizations who have already adopted
a DevOps approach to some or all of their projects, with 89% having their application
code under version control and 68% doing the same for their databases. The majority
of that group are doing issue tracking, continuous integration, test automation and
automated deployment for their application code. However, applying the same
processes to database development is much less common, and carried out by
only a fifth of respondents, even among the group who have already adopted some
DevOps practices.
9
Has your organization brought in third-party tooling to aid your

9
application development in any of these areas:
Provisioning tools 11%
Version control tools 63%
Continuous integration tools 30%
Automated testing tools 29%
Deployment tools 35%
Monitoring tools 38%
Issue tracking tools 47%
Configuration management tools 18%
Has your organization brought in third-party tooling to aid your

10
database development in any of these areas:
Provisioning tools 8%
Version / source control tools 42%
Continuous integration tools 16%
Automated testing tools 12%
Deployment tools 24%
Monitoring tools 37%
Audit tools 14%
10
How frequently does your team deploy database changes,

11
on average?
Daily 13%
More than once a week 24%
A couple of times a month 31%
Once a month 13%
A few times a year 14%
Once a year 2%
Other 3%
37% of respondents are deploying database changes either more than once a week
or daily. In the group who had adopted DevOps practices across some or all of their
projects, this figure rose to 44%, with 75% of them deploying at least twice a month
if not more.
Among those who had no plans to adopt DevOps practices, the proportion who release
this frequently was only 28%.This may indicate that this group are facing less pressure
to shorten the release cycle, which as we see in the answers to question 13 is the most
common driver.
11
Which of these do you consider to be the greatest drawback in

12
traditional siloed database development practices?
18% Slow development and release cycles
18% Inability to respond quickly to changing business requirements
26% Increased risk of failed deployments or downtime when introducing changes
9% Too much time spent on bug fixes or rework
3% Slow failure recovery rates
8% Poor visibility of the change management process
16% Lack of communication between development and operations
2% Other
We can see that overall the greatest drawback with traditional siloed database
development, is considered to be the increased risk of failed deployments or downtime
when introducing changes. This answer is closely followed by slow development and
release cycles, the inability to respond quickly to changing business requirements and
poor communication between development and operations teams.
These are the top four drawbacks identified by all of the different groups of
respondents, although their relative importance differs among larger organizations.
For those with 5001 to 10,000 employees, slow development and release cycles are
seen to be more of a drawback than application downtime. And for organizations with
more than 10,000 employees, the inability to respond quickly to changing business
requirements is deemed to be a slightly more significant downside.
The ordering of the top four answers also varied across industries, seemingly
reflecting the differing nature of the business. For the IT Services/Consulting sector,
an increased risk of failed deployments or downtime is a much greater drawback, with
38% of respondents choosing this answer. In Retail/Consumer Services, the inability to
respond quickly to changing business requirements is the top answer.
12
Which of these would be the main driver for automating the

13
delivery of database changes as part of a wider DevOps process?
To increase speed of delivery of database changes 26%
To free up developers time for more added value work 17%
To reduce risk of losing data during the deployment process 13%
To minimise application downtime 12%
To enable faster resolution of issues 11%
To more easily meet audit or regulatory requirements 4%
To facilitate better collaboration between development and operations 13%
Other 4%
Increasing the speed of delivery of database changes is the main driver overall for
applying DevOps practices to database development.
However, as to be expected, priorities slightly differ according to role and level of

seniority in the organization. Developers want to be freed up to do more added value
work while DBAs are driven by a desire to reduce application downtime and improve
collaboration between development and operations teams. IT Directors and C-level
Executives consider the need to free up developers for more added value work
as equally important as increasing the speed of delivery, and they are also more
concerned with the need to minimize the risk of losing data.
13
What would you consider to be the greatest challenge in

14
integrating database changes into a DevOps process?
32% Synchronizing application and database changes
10% Keeping up with the speed of delivery of applications
19% Preserving and protecting business critical data
9% Meeting security or compliance concerns
25% Overcoming different approaches to application and

database development
5% Other
The responses to this question suggest that applying consistency across application
and database development is a key challenge. Synchronizing application and
databases changes and overcoming different approaches the teams have to
development, are the answers most frequently cited across all groups of respondents.
14
How long do you estimate it would take your organization to

15 move from traditional database development practices to a fully
automated process for deploying database changes?
Less than 6 months 6 - 12 months 1 - 2 years More than 2 years
20% 19%
31% 30%
There is a significant difference in the estimates given for how long it would take to
move to a fully automated database deployment process between the group who are
already using DevOps processes and those who aren’t and have no plans to.
68% of those who had adopted DevOps practices in some form already cite 0 to 12
months as the time it would take to move to a fully automated database development
process, compared to 28% of those who had no plans to adopt DevOps practices.
In fact, 43% of this latter group cited more than two years as their estimate.
15
Survey Demographics
16 What is your primary job title?
Database Administrator 20%
Database Developer 8.5%
Application Developer 9%
Developer 11%
Architect 14%
Analyst 4%
DevOps Engineer 3%
IT Director or Manager 17%
C-level Executive (CIO, CTO etc) 4.%
Other 8.5%
17 What is your organization’s primary industry classification?
IT Services/Consulting 27%
Financial Services/Insurance 18%
Retail/Consumer Services 7%
Government/Education/Non-Profit 13%
Healthcare/Medical/Pharma 10%
Energy/Utilities/Telecommunications 6%
Industrial/Manufacturing 6%
Other 13%
16
18 What region are you based in?
61% 24%
North America Europe & Russia
7%
Asia
2%
South America
2% 4%
Africa Australia & New Zealand
Approximately how many employees Approximately how many of those

19 are in your organization (across all 20 employees are responsible for IT
locations)? development, engineering or operations?
% %
1 - 25 14 1 - 10 27
26 - 100 12 11 - 50 31
101 - 500 23 51 - 250 20
501 - 1000 12 251 - 500 7
1001 - 5000 18 501 - 1000 5
5001 - 10,000 7 1000+ 10
10,000+ 14
To learn more about how Redgate can help your organization to extend DevOps
practices to SQL Server databases please visit www.red-gate.com/solutions

State of Devops

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

State of Devops

Uploaded by

Copyright:

Available Formats

The State of

Tom Beavan, DevOpsGuys

Over 1000 SQL Server professionals participated in the survey, with

The greatest drawback identified with traditional siloed database development is

Increasing the speed of delivery of database changes and freeing developers up

Has your organization already adopted, or do you plan to adopt,

12% 35% 33% 20%

Unsurprisingly, lower levels of adoption were seen in the Manufacturing and

What was, or what would be, the main obstacle to implementing a

20% Lack of alignment between development and operations teams

9% Lack of support from executive leadership

21% Lack of appropriate skills in the team

17% Disruption to existing workflows/business

10% Lack of budget to invest in new tooling

17% Lack of awareness of benefits to the business

Which of these best describes how closely your developers and

20% 38% 30% 12%

25% Our team has dedicated

75% Our developers are responsible for both

5 Who typically builds database deployment scripts?

Who is responsible for the deployment of database changes

Automated provisioning 15% Automated provisioning 9%

Version control 81% Version control 58%

Continuous integration 39% Continuous integration 20%

Test automation 38% Test automation 19%

Automated deployment 33% Automated deployment 21%

Application performance monitoring 36% Server performance monitoring 50%

Issue tracking 64% None of the above 16%

Configuration management 36%

None of the above 6%

Use of source control is high, particularly as expected in application development with

Has your organization brought in third-party tooling to aid your

Provisioning tools 11%

Version control tools 63%

Continuous integration tools 30%

Automated testing tools 29%

Deployment tools 35%

Monitoring tools 38%

Issue tracking tools 47%

Configuration management tools 18%

None of the above 15%

Has your organization brought in third-party tooling to aid your

Version / source control tools 42%

Continuous integration tools 16%

Automated testing tools 12%

Deployment tools 24%

Monitoring tools 37%

Audit tools 14%

None of the above 28%

How frequently does your team deploy database changes,

More than once a week 24%

A couple of times a month 31%

Once a month 13%

A few times a year 14%

Which of these do you consider to be the greatest drawback in

18% Slow development and release cycles

18% Inability to respond quickly to changing business requirements

26% Increased risk of failed deployments or downtime when introducing changes

9% Too much time spent on bug fixes or rework

3% Slow failure recovery rates

8% Poor visibility of the change management process

16% Lack of communication between development and operations