Red gate stateofdatabasedevops report

The State of
Database DevOps
Survey on DevOps Adoption rates
among SQL Server Professionals

Survey on DevOps Adoption rates among SQL Server ProfessionalsThe State of Database DevOps
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.

4
Has your organization already adopted, or do you plan to adopt,
a DevOps approach across any of your IT projects?
1
12%
already adopted across all
projects
35%
already adopted across some
projects
33%
plan to adopt across some or
all projects in the next 2 years
20%
Not adopted and no plans to
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.

5
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.
What was, or what would be, the main obstacle to implementing a
DevOps approach in your organization?
2
20%
9%
21%
17%
10%
17%
6%
Lack of alignment between development and operations teams
Lack of support from executive leadership
Lack of appropriate skills in the team
Disruption to existing workflows/business
Lack of budget to invest in new tooling
Lack of awareness of benefits to the business
Other

6
Great
All work together effectively as
one team, using standardized
processes and tools
Good
teams collaborate together
with DBAs getting more
involved on an ad-hoc basis
when needed
OK
DBAs aren't really involved
and only work with
development when its time
for a production deployment
Poor
DBAs are completely siloed,
unaware of what's happening in
development and deploy database
changes to production in isolation
Which of these best describes how closely your developers and
your Database Administrators (DBAs) are integrated?
3
20% 38% 30% 12%
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.

7
Does your team include any developers that work across both
databases and applications?
4
Our developers are responsible for both
database and application development
Our team has dedicated
database developers
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.
75%
25%

Who typically builds database deployment scripts?5
60% Developers
35% DBAs
5% other
39% Developers
52% DBAs
9% other
Who is responsible for the deployment of database changes
to production?
6
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

9
Which, if any, of these practices are
already in place for your application
development:
Which, if any, of these practices are
already in place for your database
development:
7 8
Automated provisioning
Version control
Continuous integration
Test automation
Automated deployment
Application performance monitoring
Issue tracking
Configuration management
None of the above
Automated provisioning
Version control
Continuous integration
Test automation
Automated deployment
Server performance monitoring
None of the above
15%
81%
39%
38%
33%
36%
64%
36%
6%
9%
58%
20%
19%
21%
50%
16%
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.

10
Provisioning tools
Version / source control tools
Continuous integration tools
Automated testing tools
Deployment tools
Monitoring tools
Audit tools
None of the above
Provisioning tools
Version control tools
Continuous integration tools
Automated testing tools
Deployment tools
Monitoring tools
Issue tracking tools
Configuration management tools
None of the above
Has your organization brought in third-party tooling to aid your
database development in any of these areas:
Has your organization brought in third-party tooling to aid your
application development in any of these areas:
10
9
8%
42%
16%
12%
24%
37%
14%
28%
11%
63%
30%
29%
35%
38%
47%
18%
15%

11
How frequently does your team deploy database changes,
on average?
11
Daily
More than once a week
A couple of times a month
Once a month
A few times a year
Once a year
Other
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.
13%
24%
31%
13%
14%
2%
3%

12
Which of these do you consider to be the greatest drawback in
traditional siloed database development practices?
12
Slow development and release cycles
Inability to respond quickly to changing business requirements
Increased risk of failed deployments or downtime when introducing changes
Too much time spent on bug fixes or rework
Slow failure recovery rates
Poor visibility of the change management process
Lack of communication between development and operations
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.
18%
18%
26%
9%
3%
8%
16%
2%

13
Which of these would be the main driver for automating the
delivery of database changes as part of a wider DevOps process?
13
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.
To increase speed of delivery of database changes
To free up developers time for more added value work
To reduce risk of losing data during the deployment process
To minimise application downtime
To enable faster resolution of issues
To more easily meet audit or regulatory requirements
To facilitate better collaboration between development and operations
Other
26%
17%
13%
12%
11%
4%
13%
4%

14
What would you consider to be the greatest challenge in
integrating database changes into a DevOps process?
14
Synchronizing application and database changes
Keeping up with the speed of delivery of applications
Preserving and protecting business critical data
Meeting security or compliance concerns
Overcoming different approaches to application and
database development
Other
32%
10%
19%
9%
25%
5%
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.

15
How long do you estimate it would take your organization to
move from traditional database development practices to a fully
automated process for deploying database changes?
15
Less than 6 months 6 - 12 months 1 - 2 years More than 2 years
20%
31% 30%
19%
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.

16
What is your organization’s primary industry classification?17
IT Services/Consulting
Financial Services/Insurance
Retail/Consumer Services
Government/Education/Non-Profit
Healthcare/Medical/Pharma
Energy/Utilities/Telecommunications
Industrial/Manufacturing
Other
What is your primary job title?16
Database Administrator
Database Developer
Application Developer
Developer
Architect
Analyst
DevOps Engineer
IT Director or Manager
C-level Executive (CIO, CTO etc)
Other
20%
8.5%
9%
11%
14%
4%
3%
17%
4.%
8.5%
Survey Demographics
27%
18%
7%
13%
10%
6%
6%
13%

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
Approximately how many employees
are in your organization (across all
locations)?
Approximately how many of those
employees are responsible for IT
development, engineering or operations?
19 20
What region are you based in?18
61%
North America
24%
Europe & Russia
7%Asia
2%
Africa
2%
South America
4%
Australia & New Zealand
1 - 25
26 - 100
101 - 500
501 - 1000
1001 - 5000
5001 - 10,000
10,000+
14
12
23
12
18
7
14
%
1 - 10
11 - 50
51 - 250
251 - 500
501 - 1000
1000+
27
31
20
7
5
10
%

Red gate stateofdatabasedevops report

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Red gate stateofdatabasedevops report

Ähnlich wie Red gate stateofdatabasedevops report (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Red gate stateofdatabasedevops report