Voice of the DBA

Tag: continuous delivery

  • Off to Flowcon 2014

    With all of the work on a deployment pipeline and Continuous Integration (CI) and Continuous Delivery (CD) I’ve worked on, I thought it would be instructive to go see how the software developers build their product better. A few months ago I noticed that FlowCon 2014 was coming to San Francisco. It’s a short, easy trip for me, a 2 day conference, and I thought it would be a good chance to interact with the Thoughtworks people, as well as others.

    So I booked the trip. Even though I travel enough, I rarely go for me, and this is a good chance for me to learn. I leave this afternoon, no commitments, no presentations, just the chance for me to learn a bit.

    I’m really looking forward to seeing how people are really making software happen faster, and at a higher quality level than in the past. I’ve read a few books in preparation for this, and it’s been interesting. The first one I really liked, though it has a lot to absorb. The second two were ok.

    continuousdelivery

    Continuous Delivery – Worth the read.

    51b0kaalNnL._BO2,204,203,200_PIsitb-sticker-v3-big,TopRight,0,-55_SX278_SY278_PIkin4,BottomRight,1,22_AA300_SH20_OU01_

    Refactoring Databases – Not bad, and certainly this gives some ideas for the challenges of database changes.

    510giluHAvL._BO2,204,203,200_PIsitb-sticker-v3-big,TopRight,0,-55_SX318_SY318_PIkin4,BottomRight,1,22_AA318_AA300_SH20_OU01_

    Recipes for Continuous Database Integration – Meh

  • Continuous Database Delivery from the Command Line

    I’ve been working with Red Gate to learn more and the different ways in which we can help you ease and smooth the database deployment process. I know that I’ve dreaded deployments to production in most of my jobs, and only enjoyed them in one. The mission of one of the teams at Red Gate is to make this easier and easier and I’m learning about how they do that.

    They’ve also been working with many others in the world of software, providing them with tools, getting feedback, and learning from their experiences. One of the people that has done some work with our tools is Matt Whetton, and he wrote a piece on how he’d gotten SQL Compare to work with his version control system (VCS) to get a Continuous Integration (CI) process in place. He’s using TFS, as many of you are, though he has the SQL Source Control plug in to SSMS to make managing his database code easier.

    I won’t duplicate his process here, though it’s one that should work well. It has lots of pieces and parts, and might seem confusing, but it’s not. He describes in detail how he runs tools from the command line to build a more automated process. If you want us to do more of the work, we have an automation pack to smooth the entire process, and we’re improving it all the time.

    I would encourage you to think about building your own automated process for database changes. It might seem like adding work for no good reason, but it can pay off as you expand the process through later environments to deploy to QA, Staging, UAT, Production and any other environments you might need to. If you move to the cloud, having automated processes become even more important.

    You can also take a look at the Red Gate “Learn more about databass delivery and continuous integration” page.  We’ve got some resources up there and are looking to add more all the time.

  • Continuous Delivery Visualization

    A good one, one of the better diagrams I’ve seen.

    CD

    From http://markosrendell.wordpress.com/2014/03/03/practical-benefits-of-continuous-delivery/

    Now if we can get tooling and processes to make this work reliably for databases.

  • Continuous Delivery

    At Red Gate Software, we have a product called Deployment Manager. Its aim is to smooth and ease the process of deploying changes in your software from environment to environment, database and application code. What I like about the product isn’t that it makes the overall software development process easier, though it does. It’s that the team behind the product is using their own tool and technique to . They’re practicing Continuous Delivery (CD), even as they work to help make it easier for you to practice CD.

    That’s pretty neat. Even if you don’t want to release software that often, you have to admit that’s cool. I once worked at a company that released changes every week for well over a year, and I have to say that the development team was very proud of what we accomplished every week when the deployment was complete.

    However we didn’t release every change every week, and as the Deployment Manager team as learned, some things take longer than a week. There are particular challenges to handling the partial release of software, and while you can overcome lots of them, at times you have to delay a release. However, I’d much rather delay my release a week or two than months. The latter has happened in many places I’ve worked when a large application is being built.

    At Red Gate we do think that continuous delivery is an important skill and valuable technique in software development. This idea gathers a lot of focus at Red Gate as we build tooling to help with the challenges of implementing CD. However the idea of CD doesn’t mean that you constantly update your own software for customers. It’s entirely plausible to practice CD internally, releasing changes to test and staging environments many many times before you release a change to production. The idea in CD is that you know how to, and practice, deploying software regularly. That way you’re assured you can actually perform a release when you need to.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and Mevio . feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.