bringing database devops to visual studio 2017 - redgate devops 1 the database devops magazine from...

Download Bringing database DevOps to Visual Studio 2017 - Redgate  DevOps 1 The Database DevOps magazine from Redgate Software Bringing database DevOps to Visual Studio 2017 Why 2017 is the year of database DevOps

Post on 17-Apr-2018

214 views

Category:

Documents

2 download

Embed Size (px)

TRANSCRIPT

  • 1Database DevOps

    The Database DevOps magazine from Redgate Software

    Bringing database DevOps to Visual Studio 2017

    Why 2017 is the year of database DevOps

    Introducing DevOps into the real world

    So whats the real state of database DevOps?

    DevOps a DBAs perspective

    Spring/Summer 2017

  • 2 Shift LEFT Issue 1

    Visual Studio Enterprise 2017 now includes Redgate Data Tools rolling your SQL Server and Azure SQL databases into DevOps for higher productivity, agility and cross-team performance.

    Accelerate release cycles and increase collaboration by making your database part of the DevOps workflow.

    Learn morehttps://aka.ms/vsenterprise

    Equip your teams for better collaboration

  • 3Database DevOps

    Welcome to Shift LEFT

    These are interesting times. The recent State of Database DevOps Report revealed that 80% of companies will have adopted DevOps in two years, and 75% of developers are responsible for both database and application development.

    Visual Studio 2017 launched on March 7, and the Enterprise Edition integrates Redgate Data Tools in the installer, giving users the opportunity to introduce DevOps practices for the database alongside the application.

    DevOps is going mainstream, and the database is being seen as a natural part of DevOps rather than a blocker to the process.

    Thats quite a change and its where Shift LEFT comes in. Redgate and many of our partners are actively researching, writing about and doing database DevOps. This is the place where you can find out whats been happening, and catch up in one publication, in one place, all of the latest news.

    Welcome to database DevOps. If youre not doing it now, chances are you will be doing it soon.

    Matt HilbertEditor

    Contents

    4 Wheres the database in DevOps?6 Help me, help you, deliver DevOps8 Introducing DevOps into the real world11 So whats the real state of Database DevOps?12 Bringing database DevOps to Visual Studio 201714 The why (and more importantly the how) of automated database deployment16 DevOps a DBAs perspective19 Continuous Delivery how do application and database development really compare?22 Why 2017 is the year of database DevOps and why database professionals should lead the charge24 DevOps and Shift Left for databases28 The Phoenix Project

    EDITOR

    Matt Hilbert

    COVER DESIGN

    Anastasiya Rudaya

    PHOTOGRAPHY

    James Billings

    http://jamesbillings.photography

    DESIGN AND ARTWORK

    Pete Woodhouse

    CONTRIBUTORS

    Kate Duggan

    Grant Fritchey

    Bob Walker

    Elizabeth Ayer

    Paul Ibison

    Simon Galbraith

    Stephanie Herr

    Claire Brooking

    www.red-gate.com

    www.simple-talk.com

  • 4 Shift LEFT Issue 1

    So, what is DevOps?

    Theres a lack of clarity about what it is and a misconception that its just about automation. We hear people using the term DevOps almost interchangeably with automation or even tooling to some degree, but its actually more about the culture. DevOps is about creating the right environment and the right kind of team to become collaborative and work towards a shared goal of delivering software effectively. Automation will help you achieve that but you need a DevOps mindset first.

    How do you get the buy-in to create that culture of change if its not just about plugging in a tool? Tools can be accelerators and they can also be a way in. But ultimately its about breaking down walls and barriers and bridging the gap. That could mean realigning your teams or changing your organizational structure, so you need a high-level buy-in and the right kind of culture to be accepting of this movement. It can be quite a challenge.

    We hear about companies like Netflix and Etsy using a DevOps approach, but how well is it being adopted in the mainstream? There are some large companies out there who have famously adopted this highly automated approach to delivering software. But were not all Netflix and we havent all got automation baked into our DNA. There is no one size fits all solution for DevOps for every organization, so you do need to tailor the solution to your own business. The way one company does it might be a roaring failure in another organization because there are so many different ways of adopting DevOps.

    Interview

    { kate duggan }

    Wheres the database in DevOps?

    James Betteley, Head of Education at IT consultancy DevOpsGuys, is a firm believer that DevOps is about people and processes, and that while automation tools are necessary, they are not sufficient for a team to be a DevOps team. But where does the database come into the picture? Kate Duggan interviewed James to find out.

  • 5Database DevOps

    Should DevOps goals be the same as company goals? How important is this alignment?

    Your company goals will have a huge impact on what your DevOps goals are. DevOps goals need to be tightly coupled with your IT strategy. Your IT strategy and a lot of your DevOps techniques need to be working towards your business goals; otherwise, youll be fighting the whole way.

    So how does the database fit into DevOps?

    The database is as important a part of the ecosystem as any other part of the application. It is as important as your infrastructure or your website. So asking Wheres the database in DevOps? is a bit like asking Wheres the website in DevOps?. At the end of the day, its a culture, a way of working, and your database fits in there alongside everything else. The main thing is to get the right people in the room at the right time from the beginning, and design solutions sympathetically with consideration for the database and the architecture of choice. We need to be thinking about how we deploy, how we maintain, how we roll back, and all of those things. Traditionally the database has been difficult to fit into this, and has always been the sticking point in the past. But there are now good tools out there to support the database, so we dont have to just hit and hope any more.

    Why do you think the database hasnt been included before in practices like continuous integration and automated testing?

    It was too hard to do. Wed been used to developing code that you could just tear down and replace, but Database Adminstrators would say You cant do that with your data and your database. So instead of working together to come up with best practices and elegant solutions, developers ended up saying Okay, thats your problem, so Ill leave it with you. There were all these automation tools available in development, but in operations they were still doing a lot of tasks manually. Thankfully, now there are solutions so we can finally work together. Ive seen the change happen firsthand its been a cultural change as much as anything else, and new tools are sweeping in that also help us be more collaborative.

    Once an organization has decided to adopt a DevOps model, would you typically see a big bang change to the new way of working, or a more gradual approach, starting with specific projects or databases and adopting more as time goes on?

    It will all depend on your organization its current size, existing culture, structure, and many other factors as well. However, I think its fair to say that a more gradual approach is far more likely to be successful than a big bang. At DevOpsGuys, we usually recommend that organizations start on a smaller, isolated product, and concentrate on making a successful transformation within that product team. Once the fire of success has been lit, you then need to fan the flames and spread that success to other teams and across the organization.

    So the smaller an IT team, the easier DevOps is to implement?

    Possibly, because youll have fewer people to convince! But generally speaking, I dont think its down to the size of your IT department. You see large organizations with hundreds of IT people broken down into smaller product teams; thats the favored framework for being successful with agile and DevOps. Collaboration is the main issue, in just the same way as its easier for smaller teams and organizations to become agile. But just because it might take a bit longer to adopt DevOps in a larger organization, it doesnt make it any less valuable.

    What would be the first step or steps to applying a DevOps approach to an already deployed application and database?

    If you mean DevOps best practices, such as automation, then the answer would be to start with version control. Version control, or source control, is a fundamental part of getting your database to work more like your application. The ability to deploy to a known state is only really possible by using the mechanisms within a version control system. Reports like The State of DevOps from Puppet Labs have told us that organizations using version control and automated deployments are higher performing so we know its a good thing to do! Its only a small part of the bigger DevOps picture but its still a very important part, and a key step along the DevOps journey. By version controlling your database, you make it easier to share and collaborate, find and fix issues earlier, and be able to deploy a known state. Plug in some continuous integration and deployment automation and youre well on your way.

    Any final thoughts?

    DevOps is primarily about people and processes. While automation and tools are necessary, theyre not sufficient for a team to be a DevOps team. You also need to ensure youve got support from the team and organization around you if youre hoping to start adopting DevOps-like practices.

  • Help me, help you,deliver DevOpsI believe in DevOps. Actually, thats a pretty horrib