In my current project we have a lot of .NET Core API projects that serve different clients, mainly a React webapp. Some of these APIs are only facades in front of older poor written APIs from external vendor systems. The reason we went for facade APIs are that some of these system have rate limiting and others are extremely slow (some are both). With our own APIs we can cache a lot of the data and deliver most of our querys directly from the much faster Redis cache. With this solution we can also scale out across the globe and not be reliant on vendors doing that for us.
The main problem with this is keeping the cache fresh and this is where our webjobs come in to play. We decided on webjobs over functions because the ease of maintenance, running the jobs in the same service as our API. Basically we have a mix of triggered and continuous jobs, the triggered ones run on a schedule depending on the vendor API limits and the continuous ones listen to servicebus messages.
There's a SDK for webjobs that makes it really easy to develop and deploy these kind of things, problem is that it doesn't have support for .NET Core and certainly not .NET Core 2.x that we're using. Luckily for us you can run a standard console application as a webjob. The problem is deployment, all the guides point to the following steps.
- Publish your console app to a directory
- Zip your directory
- Manually upload it via the Azure portal
This isn't really acceptable in a CI/CD scenario so we had to find a way around this.
When we deployed our webjob manually I was curious what actually happened and it turns our to be rather simple. The uploaded zip is just extracted in to a specific folder inside ~\App_Data\jobs\ depending on if it is a triggered job or a continuous one.
Triggered jobs ens up in
\App_Data\Jobs\Triggered\<nameofjob> and continuous ones end up in, you guessed it,
I ended up creating a publish step in VSTS that publish our webjob command line project directly in to this folder structure so when we publish our artifact to the release pipeline it already contains the webjob. The Azure app service automatically picks up that there's a webjob installed and starts running it accordingly.
API publish step
WebJob publish step
Remember to not zip your published projects otherwise it won't include the second step in the artifact correctly.