Alternate Azure Webjob Deploy….

Update:

Since original posting, webjobdeploy can now deploy Azure App Services as well (using -deploy appservice flag). Definitely becoming very handy 🙂 Although now might have to consider a rename 😉

———

I’ve recently found myself needing to deploy Azure webjobs fairly frequently. Now, once I have everything rigged up to Azure Devops everything will be easy, but for now as I’m tinkering on my local machine I’m after an easy way to do a quick deploy of one (or more) webjobs.

Now, of course I could just use the Powershell commands or the brilliantly useful AZ command provided by Microsoft…… but…… I wanted something that suits my rather awesome level of laziness. Enter webjobdeploy (or wjd, man I’m good at naming things).

The idea (whether good or bad) for webjobdeploy is to minimize how much you need to type to get your binaries deployed to Azure. Yeah, I know it shouldn’t be a concern… but it is.

Say you have the binaries for a webjob (here I’m talking about an executable that will run as a webjob) in c:\temp\mywebjob. The way you’d deploy it using webjobdeploy is:

webjobdeploy.exe -uploadpath c:\temp\mywebjob\ -appServiceName myappservice -webjobname mywebjob -webjobexename mywebjob.exe -username neveryoumind -password ditto

Hopefully the parameters are self explanatory, with possibly the exception of webjobexename . The API I use to upload the binaries needs to know what the name of the executable (whether exe, bat, cmd etc etc) is, hence that parameter.

So, you’ll end up with a webjob called “mywebjob” running under the context of the application service “myappservice” (which needs to be already created). So all is good and simple.

I modify my webjob and want to redeploy. Yes, I can “up arrow” and do that, or I’d like to preferably have an alternate method.

Webjobdeploy can store many of the parameters you provide, tied to the app service name you provide. For example, say I want webjobdeploy to store various parameters such as webjobname, webjobexename, username, password etc etc… I’d modify the above command to look like:

webjobdeploy.exe -uploadpath c:\temp\mywebjob\ -appServiceName myappservice -webjobname mywebjob -webjobexename mywebjob.exe -username neveryoumind -password ditto -store

Then for the second deployment I could use the command:

webjobdeploy.exe -uploadpath c:\temp\mywebjob\ -appServiceName myappservice

Here I’m telling webjobdeploy where to find the binaries (c:\temp\mywebjob) and which appservice to use. What happens in the background is that wjd checks to see if it has saved any config data for the app service specified (since deployments are really fairly specific to app services). If it finds credentials it will use those but any parameters passed in on the command line take precedence.

For example, say I’d already deployed the webjob as “mywebjob1” but now I wanted to deploy an alternate webjob so I could compare side by side, I could simply execute the command:

webjobdeploy.exe -uploadpath c:\temp\mywebjob\ -appServiceName myappservice -webjobname mywebjob2

Now I have the second instance of the webjob running almost instantly.

Yes, this really doesn’t give you anything Powershell or AZ doesn’t already provide…. but I do find it useful for rapid webjob turn arounds.

IMPORTANT NOTE: The configuration that is saved is currently NOT encrypted. This means your username/password are plain text (stored within your home directory). Yes this is bad… yes, this is hopefully only temporary. But if your local home directory is already compromised, then you might have bigger issues to hand. Not an excuse, just an observation 🙂