The Primal Urge to Deploy

I've talked before about my love for PrimalScript as a VBScript and JavaScript editor. It's just got some features that I've grown to really love. Well unfortunately I just don't get the chance to use it that much anymore because most of the web coding I do is in .NET and I tend to do all that coding in Visual Studio for all the class helpers and such. And since I'm a DBA, and not a Windows admin, I just don't d

I've talked before about my love for PrimalScript as a VBScript and JavaScript editor. It's just got some features that I've grown to really love. Well unfortunately I just don't get the chance to use it that much anymore because most of the web coding I do is in .NET and I tend to do all that coding in Visual Studio for all the class helpers and such. And since I'm a DBA, and not a Windows admin, I just don't do that much Windows scripting... though it does happen every couple months or so.

Well, now I'm going to get to use PrimalScript more because I've just figured out a new use for it and I just can't believe it took me this long to think of it. See, PrimalScript has this script packager that will package up all of your scripts into an exe so you can put them out there for users without having to worry about them getting at your connection strings or changing the logic. And that's how I've always used it in the past. But it just hit me a couple weeks ago that I can use it to deploy my DB scripts too. See, like many shops, we have to send our deployment scripts to an official change manager who then deploys them into production. It's that whole separation of duties thing we all love so much. Well anyway... the problem is simple... if we send him our scripts, which number in the tens sometimes, we have to make sure we tell him what order to run them in, and then trust that he does it correctly. And then if something blows up there's always that argument about whether the scripts were right or whether he changed something by mistake. Then there's the problem of whether he should deploy to all of our systems because we don't want him to have SQL rights on all of our boxes, etc. So you can see how the process can get fairly complicated and even counter-productive at times.

Enter PrimalScript... now I'm packaging up all my scripts and just sending him an exe that all he has to do is run. In fact, I can put them in order, and even call them with whatever account I like and he can actually deploy code to boxes he doesn't even have rights on. I'm telling you, that's just fabulous.

It's actually pretty easy. All I have to do is specify a .vbs file with a series of osql statements in it. Each osql statement uses an input file as it code source. So whatever script you generate, just point it at the file and you're done. Then inside PrimalScript, you attach the vbs as the script to run, and attach the SQL scripts as data files. They all get compiled up with the exe and you can send the entire set as a single build to your deployment team.

Now the arguments just don't exist anymore. You know the scripts ran in order, you know nothing was changed, and you know they ran under an account that had rights to perform all the actions. Personally, I'm in love.