Continuous Integration

It seems like a magic silver bullet: Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. It means that everything should stay inline, that no-one steps on anyone's toes. That all should be shiny and lovely and

Oh. Hang on.

Didn't we all learn in Comp Sci 101 that there's no such thing as a silver bullet? I'm sure that turned up on my course 14 years ago: and Continuous Integration has been around since well before then (1991 if we believe wikipedia). Mind you, my Comp Sci course also involved the networks tutor getting very excited about 10BASE5 thick coax, when possibly he should have been getting nostalgic about it.

So. Anyway. Continuous integration is supposed to make it much easier for everyone to work together. And, in order to work together, you need good tools. You need to be using the same tools, you need the tools to work together without causing conflicts, and, crucially, you all need to be using the tools properly!

Enter Redgate. Hurrah!  I do rather have a DBA crush on Redgate. They've made my life so much simpler in so many ways (except for discontinuing Hyperbac. I did rather love Hyperbac, and I still have it running on the one SQL 2000 box that we're trying to decommission. It works. Period.).

Back in March, I went on the Continuous Integration Workshop hosted by Redgate. Primarily, I wanted to understand how CI works - we've got some source control in place where I work, but it very often feels that developers are stepping on each other's toes, that we're not always testing as robustly as we might, that our databases are completely out of step between environments, and, as DBA, I'm running scripts and copying databases from Live to Test to Dev more than I might otherwise like.

By the end of the day: I could see how it was supposed to work in the world of databases. From a standing start (I've not been involved with our Developers' source control system at all, and I can't exactly say I'm intimate with TFS), we looked at how to use SQL Source Control to link to a source control system - it works with pretty much any system, and DLM Dashboard (their super, free, product - which I had a lot of fun testing last year) to keep track of changes, to be informed as databases changed, and to automate the process. I took copious notes.

And, the automation of the process would be fantastic. Because this morning, I ran a script a whole week early, and had to roll it back again fairly pronto. On the plus side, I'd taken a backup before I'd got going, so I could restore that on the Dev box and then use SQL Data Compare, which made it an absolute doddle to establish which rows in the Live database had been updated, and to roll them back, based on a comparison between the two versions of the database.

(Did I say I love Redgate?)

Disclaimer: Redgate are offering me a free place at a Redgate Workshop in return for posting.

SSRS Parameters

I keep searching for the same default values for my date parameters.

Enough! Time for a list!

Yesterday 

=DateAdd("d",-1,Today())

Monday of last week

=DateAdd(DateInterval.Day, 2-WeekDay(Today), DateAdd(DateInterval.Day, -7, Today))

Friday of last week 

=DateAdd(DateInterval.Day, 6-WeekDay(Today), DateAdd(DateInterval.Day, -7, Today))

First day of last month

=dateadd("m",-1,dateserial(year(Today),month(Today),1))

First day of this month

=dateadd("m",0,dateserial(year(Today),month(Today),1))

First day of next month

=dateadd("m",1,dateserial(year(Today),month(Today),1))

Last day of last month

=dateadd("m",0,dateserial(year(Today),month(Today),0))

Last day of this month

=dateadd("m",1,dateserial(year(Today),month(Today),0))

Last day of next month

=dateadd("m",2,dateserial(year(Today),month(Today),0))

One year ago

=DateAdd("yyyy", -1,Today())

First Day of this year

=Today.AddMonths(1-Today.month).AddDays(1-Today.day)

More to come...