Continuous Delivery In Real Life

I’ve been writing and presenting on Continuous Integration (CI) and Continuous Delivery (CD) for a few years now. In that time I’ve encountered a lot of excitement and a good deal of skepticism as well. Many people want to know more and more, who is actually using this stuff? It’s nice to talk about Spotify and Netflix, but their problem domain, resources, and above all, youth, are something few organizations deal with.

What about Microsoft? They’re a large organization, fairly mature (now 40 years old), and have their own levels of bureaucracy to manage. However they’re fundamentally changed the way they perform development across the last decade and a half. Starting in the beginning of this century, they moved to make secure coding a priority. In the last few years, they’ve also started to truly speed up their development process with CI and CD, culminating (now) with an extremely quick Windows 10 development pipeline.

I saw a piece noting Microsoft is releasing almost daily builds of the new OS. That’s an amazing feat of engineering, and certainly one that shows you can develop an efficient software pipeline. While I’m sure that individual engineers don’t necessarily have their code released daily, that’s not the point. The point is that changes can be checked into version control (please, please do this), tested, and then made available for release.

You can build software this quickly, too, though not in a day. Probably not in a month. I would guess it will take a year or two for many organizations to assemble the processes, change a bit of culture, and get used to building your application daily. Above all, it will take time for you to build unit tests and get them automated. You’ll have issues along the way, and it will be painful, but isn’t releasing software painful for most groups right now?

A year or two sounds like a long time, but really it isn’t. Look back a year at your company and job? How much have your process changed? If it isn’t a lot, doesn’t that feel like you could have done something to improve the way you release software? Is there the possibility of making a smoother process that makes it easier to get enhancements to customers? I’m sure there is, and I hope you think about starting to assemble your own software pipeline today with CI and CD. Take baby steps, and slowly make changes to automate and standardize your deployment process.

Steve Jones

The Voice of the DBA Podcast

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

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial. Bookmark the permalink.

4 Responses to Continuous Delivery In Real Life

  1. Hi Steve, why would it take a year or two to set up daily builds? With TFS/VS/ccnet/MsBuild you can easily have check-in based builds. no?

    • way0utwest says:

      It’s not a year for CI. It’s a year or two for a CD process. Deploying software from developer check in to releasing to clients/production systems. It’s probably slower on the database side than application side, but a smooth process takes time.

      The CI setup is simple. That’s a few hours, but getting everyone to use version control, especially for databases isn’t easy. Writing tests and getting them scheduled as a part of your builds, isn’t easy. Above all, the process of checking results and fixing breaks in the build is a habit you to build. Setting up scripts or tools to deploy changes to other environments, takes time.

      The technology is easy, and it’s hours, or days. The culture and habits take longer.

  2. I think it’s a matter of policy. If you allow people to dilly dally, they will. 🙂 As long as you offer a workflow that “works”, there should be no excuses. For example,
    – source controlling your DB you can use Visual Studio database projects. I have yet to encounter a database that it couldn’t handle. (I know there are other options, but it’s just an example) Let’s say for simplicity sake that you use TFS as a back end.
    – msbuild can handle building your DB solutions. I’ve often used powershell scripts to enforce naming conventions, an alike.
    – create your dacpac and publish it. This method may be too crude for a refined DBA taste, but for a dev env I think it’s adequate.

    and that’s it, really. If this is the only option available and it works, compliance will be 100%. At the end of the day every developer just wants to do his/her work and get the product out on time. If we can give them the right tools to easily do it without breaking the database culture and habit will no longer be a factor. Don’t you think?

    • way0utwest says:

      I’d disgree. Lots of people want to get work done. I think it’s as much perfectionism as dilly dallying.

      However, changing the way someone works is hard. Many people don’t want to change their process, or they worry another process will slow them down, or they’ll develop poorly if they change.

      I do think there are ways to get things to work well, but the dacpac isn’t as simple as just publishing it. MAybe in some situations, but in lots of them there have been complex pre/post scripts needed, and still some holes.

      There’s also greenfield (new) v existing projects. Those can be hard to move to a new process.

Comments are closed.