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

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




2 download

Embed Size (px)


<ul><li><p>1Database DevOps</p><p>The Database DevOps magazine from Redgate Software</p><p>Bringing database DevOps to Visual Studio 2017</p><p>Why 2017 is the year of database DevOps</p><p>Introducing DevOps into the real world</p><p>So whats the real state of database DevOps?</p><p>DevOps a DBAs perspective</p><p>Spring/Summer 2017</p></li><li><p>2 Shift LEFT Issue 1</p><p>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. </p><p>Accelerate release cycles and increase collaboration by making your database part of the DevOps workflow.</p><p>Learn more</p><p>Equip your teams for better collaboration</p></li><li><p>3Database DevOps</p><p>Welcome to Shift LEFT</p><p>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.</p><p>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.</p><p>DevOps is going mainstream, and the database is being seen as a natural part of DevOps rather than a blocker to the process.</p><p>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.</p><p>Welcome to database DevOps. If youre not doing it now, chances are you will be doing it soon.</p><p>Matt HilbertEditor</p><p>Contents</p><p>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</p><p>EDITOR</p><p>Matt Hilbert </p><p>COVER DESIGN</p><p>Anastasiya Rudaya</p><p>PHOTOGRAPHY</p><p>James Billings</p><p></p><p>DESIGN AND ARTWORK</p><p>Pete Woodhouse</p><p>CONTRIBUTORS</p><p>Kate Duggan</p><p>Grant Fritchey</p><p>Bob Walker</p><p>Elizabeth Ayer</p><p>Paul Ibison</p><p>Simon Galbraith</p><p>Stephanie Herr</p><p>Claire Brooking</p><p></p><p></p></li><li><p>4 Shift LEFT Issue 1</p><p>So, what is DevOps?</p><p> 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.</p><p>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.</p><p>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.</p><p>Interview</p><p>{ kate duggan }</p><p>Wheres the database in DevOps?</p><p>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.</p></li><li><p>5Database DevOps</p><p>Should DevOps goals be the same as company goals? How important is this alignment?</p><p> 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.</p><p>So how does the database fit into DevOps?</p><p> 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.</p><p>Why do you think the database hasnt been included before in practices like continuous integration and automated testing?</p><p> 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.</p><p>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?</p><p> 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.</p><p>So the smaller an IT team, the easier DevOps is to implement?</p><p> 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.</p><p>What would be the first step or steps to applying a DevOps approach to an already deployed application and database?</p><p> 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.</p><p>Any final thoughts?</p><p> 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.</p></li><li><p>Help me, help you,deliver DevOpsI believe in DevOps. Actually, thats a pretty horrible way to put it. Its not about belief, like keeping Tinkerbell alive.</p><p>I have successfully worked within an environment that implemented a DevOps approach to development, deployment and maintenance. I also provide classes and consulting on how to approach DevOps from the Ops perspective as well as writing books on the topic.</p><p>Because Ive seen the DevOps approach work, and work well, despite the fact that my principal job description is in the Ops side of DevOps, I am a very strong and passionate advocate for DevOps.</p><p>But!</p><p>Despite the fact that I absolutely support the concepts of DevOps, moving development and deployment into the production space, and moving operations into better support of the development space, I frequently find myself, with my face, in my palm.</p><p>Why?</p><p>Look at the word, DevOps. Note: it doesnt say Dev. It doesnt say DEVops. It doesnt say Dev ops. The core concepts behind DevOps is that development and operations are coming together. Its not that development is taking over operations, as I so frequently have to argue about, with both development and operations.</p><p>This is an important and key concept because theres a reason why you see some specialization within IT. Frankly, IT is difficult. So people spend time learning smaller aspects of it in order to be good at those aspects. Yes, acknowledged, there is the very rare individual who truly is a superstar and can do it all, but they are, by definition, extremely rare on the ground. Most of us in IT are just ordinary humans.</p><p>{ grant fritchey }</p><p>Opinion</p><p>6 Shift LEFT Issue 1</p></li><li><p>7Database DevOps</p><p>OperationsI get it. To developers, the operations team just seems like this slow moving behemoth, a dinosaur on its way to the tar pits (yeah, I know, mainly mammals in the tar pits from a different era work with me). Especially the DBA team (No!) and their ability (No!) to slow things down (No!) with their constant (No!) use of the word, No (No!).</p><p>However, operations exists for a reason, and theyve developed a lot of special skills and knowledge that seems to be missing from development. Let me outline what I mean.</p><p>FailureThere have been quite a few spectacular failures recently. Lets talk about how a fundamental lack of understanding of why ACID properties on a database are kind of important, especially when setting up something that resembles a bank.</p><p>No? How about the fact that backup testing, a pretty fundamental aspect of operations is so easily overlooked. Not to mention evidently being able to use the same login in dev/test and production so that you can corrupt and then drop the production database accidently.</p><p>Maybe that you need a secondary location for your Disaster Recovery? Seems like a pretty fundamental part of operations.</p><p>Or even my own web site. I didnt maintain my updates appropriately (and I know better) which allowed me to be hacked. Happily, I have two sets of backups, one I maintain myself and one maintained by my wonderful service provider, Dreamhost. Recovery was possible in under an hour.</p><p>Speaking of backups, maybe taking them at all would be a good idea.</p><p>KumbayaNot all those losses and outages are even remotely the fault of DevOps, but you do get the sense in our ever more development-focused age that, maybe, a little more attention ought to be paid to the Ops side of things and then we can all hang out, singing kumbaya instead of running around putting out fires.</p><p>The key concept of DevOps is that we meet in the middle and cross over. Its not that one side takes over the other. The old days where things were Ops-centric were silly, and failed. Lets not repeat those mistakes by going completely Dev-centric.</p><p>Lets just do DevOps.</p></li><li><p>8 Shift LEFT Issue 1</p><p>During the aftermath, my team of developers worked closely with operations, rolling back to a stable state, diagnosing the cause of the problem, working on a solution, and discussing ways the whole situation could have been avoided. As painful as it was, it occurred to me at some point that this was the first time Id had a chance to collaborate at length with our operations team, and that I was enjoying it.</p><p>I didnt know it then, but it was the start of my journey into DevOps.</p><p>Deployment time bombs</p><p>This event and its aftermath forced me to reflect on how the various teams hadnt really been working together as well as they could up to that point. Like most development shops Ive worked for, there was not a lot of collaboration between my team of application developers and the operations team (Database Administrators or DBAs, Web Administrators, and System Administrators).</p><p>Developers would write the code and throw it over the wall to the operations </p><p>team whose responsibility was to deploy it and keep things running smoothly. By the time the operations team had a chance to look at the changes, it was far too late in the development lifecycle; those changes had to go live.</p><p>Unfortunately, on this fateful day, our code contained a time bomb some new code that just didnt work on the live system. To stop the hemorrhaging, we rolled back to a working state, and then embarked on a triage process with the operations team. We learned a lot during the process. Most of us </p><p>Introducing DevOps into the real world</p><p>About two years ago, my team deployed a production change to the system we were responsible for maintaining and developing. It wasnt a significant new version; just one minor new feature and a couple of bug fixes. Shortly after our operations...</p></li></ul>


View more >