Hot Fixes

, 2007-04-03

I wrote about Hot Fixes being inclusive of previous hot fixes. Someone questioned this and so I went back to Simon's blog and checked his source. He's a SQL Server MVP (and a great guy, I got to meet him at the Summit last year) and he got it from the MVP Summit.

I think it's controversial, mostly becuase I and many others, assumed that each hot fix was independent, but if you stop and think about it, as I have been doing, it makes sense. No one wants to maintain multiple code bases. It's hard and in vastly increases the chances for problems. Plus merges might be the least favorite thing for people to do, even less liked than bug fixes.

Think about it, you have SQL Server, this huge, multi-million lines of code software product. Suppose you have modules 1-5 to keep things simple. If there's a problem in module 2, you branch the code and start working on a Hot Fix. Now you also have work going on for the next service pack in Modules 3 and 4. You finish this patch and you have this:

Main branch               Hot Fix 1 Branch
  - Module 1                   - Module 1
  - Module 2                   - Module 2 patched

  - Module 3 (updated)   - Module 3
  - Module 4 (updated)   - Module 1
  - Module 5                   - Module 1

We have two branches and they can easily be merged at this point. Now suppose we're still working and someone finds a bug in Module 3. Now what do you do? You can branch again and get this

Main branch               Hot Fix 1 Branch              Hot Fix 1 Branch
  - Module 1                   - Module 1                   - Module 1
  - Module 2                   - Module 2 patched      - Module 2

  - Module 3 (updated)   - Module 3                   - Module 3 patch in progress

  - Module 4 (updated)   - Module 1                   - Module 4
  - Module 5                   - Module 1                   - Module 5

or work with your old branch

Main branch               Hot Fix 1 Branch
  - Module 1                   - Module 1
  - Module 2                   - Module 2 patched

  - Module 3 (updated)   - Module 3 patch in progress

  - Module 4 (updated)   - Module 1

  - Module 5                   - Module 1

But in either case, you have work to be done in merging. If this continues with 5 hot fixes, then the first scenario here gives you problems with many merges, 5 in all. And what if you need to make a second patch to Module 2. Not fix the first patch, but a separate problem? Then you'd have two merges in this module. Expand this to the hundreds of modules in SQL Server and you might have an idea of the problems.

The best solution is to perform builds using good code. Which means if you have modules that are works in progress, you ignore the current version and build with the last known good version. Which is what happens. So the best idea is something like this:

Main branch              
  - Module 1              
  - Module 2 (hot fix in progress)              

  - Module 3
  - Module 4
  - Module 5

then

Main branch              

  - Module 1              

  - Module 2 (patched)              

  - Module 3 (being updated, build with last known good for hot fix)

  - Module 4 (being updated, build with last known good for hot fix)

  - Module 5

then we find a problem with module 3

Main branch              

  - Module 1              

  - Module 2 (patched)              

  - Module 3 (being updated, work on new hot fix with current version. Maybe delay unti update is finished or do both at once)

  - Module 4 (being updated, build with last known good for hot fix)

  - Module 5

etc. It's still dicey when you have a problem with an area and a separate hot fix, but you're Microsoft. Throw a few more people at it to get it done quicker. Even comment out changes in code that are work in progress.

Rate

Share

Share

Rate

Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.

2009-02-23

1,567 reads

Networking - Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I'd like to talk about social networking. We'll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let...

2009-02-17

1,530 reads

Speaking at Community Events - More Thoughts

Last week I posted Speaking at Community Events - Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I've got a few more thoughts on the topic this week, and I look forward to your comments.

2009-02-13

360 reads