Allo!
Rundeck fait le café, mais n'est pas la plus belle interface (ni la plus pratique)
La feature que je trouve indispensable : l'import export yml/json qui peut être fait depuis l'interface, ou directement en le pluggant sur un dépot git. Les crons c'est peut être des petits scripts de rien du tout, mais ca reste du code.
Tu peux éxécuter les tasks direct depuis le serveur de scheduling, ou bien via SSH/WinRM/Saltstack/etc... sur des serveurs distants
Ca gère les workflow entre plusieurs scripts/jobs, les secrets, les oneliner, mais aussi des scripts complexes, la possibilité d'éxécuter sur un groupe de serveur, sur N serveur d'un groupe, sur X% de serveurs d'un groupe, etc...
Tu peux également t'en servir comme interface d'abstraction pour des jobs métiers avec gestion des paramètres très poussés (pas de validation, validation regexp, liste exhaustive ou par un call d'API).
Bref, café, thé et tisane.
Par contre attention à la gestion de la DB si tes outputs sont gros et/ou très fréquents ! Ca deviens plus facile à clean avec les versions récentes qui permettent de purger les exécutions plus facilement.
Solution que j'ai retenue pour palier à ca : BDD postgres/mysql (aucune diff d'après mes tests) pour les datas internes et stockage des logs d'éxécution sur un stockage externe S3-Compatible : l'avantage c'est que combiné aux jobs stockés dans Git, tu n'a rien sur le serveur en lui même. Tu backup la conf, la BDD, le git et le S3-Like. En tout cas La DB H2 intégrée par défaut n'est pas utilisable en prod.
Actuellement j'ai un déploiement avec +3 million d'éxécution enregistrée et des logs qui dépassent fréquemment les centaines de Mo (oui c'est pas beau, blame the devs :) ) et ca passe crème. J'ai du occasionellement purger des jobs avec des outputs de plusieurs Gb qui ne lui plaisait pas, mais c'est des cas extrèmes (je te laisse balancer un log de 3G à syslog pour voir ce qui va se passer :) )
Seul vrai point noir : l'interface peu friendly.