I got a web job that has multiple routines, and for execute a specific routine, the routine's name is passed as job's argument. All these routines must be executed, and there's a dependency between them (a routine's input might be other routine's output); so for orchestrate this, I'm planning to use a Logic App which actually would call the same web job, but passing different parameters.
By doing all above, I'd have a single web job instance, and I'd control job flow by using a Logic App. But here's come my concern... let's suppose I only want to execute a specific routine (which is standalone, it doesn't have a dependency to another routine) because it failed (or maybe I want to debug it), so I have to go the my Web Jobs portal in Azure, and copy the job's web hook url, set the job parameters as query parameters for call the routine desired, and then call it through a HTTP client. But the problem that I see with this is that isn't that friendly: I have to do all these stuffs for call a specific job's routine.
To resolve my above concern I was planning to duplicate the job instance (the duplication term used here it's not for scaling, it's for flexibility), and hardcode the routine's name into each job duplication. The only pros that I see is run a specific routine by just going directly to its respective job instance, and click in "Run" button (Azure Portal). But also, the cons that I see here is that I'm duplicating the same source code (the same binaries), but just passing a different parameter (in this case routine's name), so in term of maintainability, it's a pain because if something changes in the job source code, I have to redeploy "routines count" times for consistency (all jobs are running under the same source code).
So should I sacrifice code maintainability (redeploy many times the same source code, and play with job parameters) for get a friendly way for job execution, or not? I'd like to hear your opinion! If there's more information needed, please let me know!