Jobs-as-Code : l’automatisation pour développer des applications de meilleure qualité et plus rapidement

Le but est d’impliquer les développeurs dans la gestion quotidienne de leur application en leur donnant les moyens de tirer profit des outils d’infrastructure.

Dans les processus DevOps, l’automatisation fait gagner du temps, économise les ressources, réduit les erreurs et assure la cohérence. Malgré tout, les développeurs persistent à ignorer l’existence de solutions de très haut niveau pour l’automatisation des processus batch et l’ordonnancement des travaux, préférant s’en remettre à des outils basiques pour la programmation du code de leurs applications (Cron, Windows Task Scheduler…).

Le développement et la production reste au sein des entreprises deux mondes distincts qui peinent à communiquer. Le simple concept « d’exploitabilité applicative » est compris de deux manières très différentes. Le développeur pense déploiement, la production pense gestion quotidienne. Du fait que ni ces outils ni les programmeurs ne respectent les mêmes standards, les applications mises en production ne répondent souvent pas aux exigences opérationnelles. Si bien que, dans l’éventualité d’un problème, celui-ci est fréquemment difficile à diagnostiquer et à corriger.

Etant donné le volume de traitement applicatif exécuté par des outils d’infrastructure d’ordonnancement des travaux (Job Scheduling), l’automatisation de la création de ces tâches permettra non seulement d’accélérer le développement, le test et de déploiement mais aussi, pour les développeurs, de consacrer plus de temps à optimiser la logique de leurs applications métiers. Le terrain montre que 80% des développeurs n’ont même pas conscience de l’existence d’un ordonnanceur utilisé en production. A l’inverse les 20% restant peuvent être très qualifiés sur cette solution.

Standardiser et automatiser

Penchons-nous sur la constitution d’une application. Le code, par exemple Java ou Python, met en œuvre la logique métier. L’application fonctionne sur une infrastructure, que ce soit un serveur Linux, un serveur applicatif web ou un réseau. Des requêtes de base de données SQL créent des tables et actualisent des index. Enfin, un grand nombre de tâches et de travaux interdépendants doivent s’exécuter, souvent dans une séquence bien précise. Cet ordonnancement détermine simplement à quel moment telle ou telle tâche doit être lancée et que faire en cas d’échec ou d’impossibilité de la réaliser à l’instant prévu. Lorsque les développeurs consacrent une part aussi importante de leur travail à la définition de cette fonctionnalité, essentiellement administrative, ils perdent non seulement du temps, mais cela engendre également des casse-têtes et pertes de temps supplémentaires pour les services opérationnels.

Le concept « Jobs-as-Code » consiste à standardiser et automatiser l’ordonnancement des travaux par l’intégration de code au moyen d’une notation simplifiée (JSON) qui effectue des appels API à un moteur d’ordonnancement, puis à gérer ces appels tout au long du cycle de vie de l’application, de la même manière dont est géré le code source compilé de l’application. Jobs-as-Code ne diffère donc pas fondamentalement des autres pratiques de gestion du code dites DevOps. Le but est donc d’impliquer les développeurs dans la gestion quotidienne de leur application en leur donnant les moyens de tirer profit des outils d’infrastructure.

Ne pas voir les travaux en termes de logique métier

L’ordonnancement des travaux est une simple instrumentation. Sa programmation demande des efforts non négligeables pour la création, le test et le support des processus, sachant que toute erreur ou incohérence risque de se répercuter au niveau opérationnel. Un ordonnanceur capable de gérer les relations entre flux, d’analyser les succès ou échecs, de capturer les résultats en sortie et de prendre en charge les autres fonctions, assurera la cohérence au sein d’une application et entre applications, ce qui se traduira par des gains de temps et une réduction des problèmes tant au stade du développement que des opérations.

Tester rapidement et fréquemment

Aujourd’hui, la syntaxe du code source est vérifiée au fur et à mesure de sa création. Procédez de même pour la définition des travaux batch. Dans les environnements de développement traditionnels, tout ordonnancement nouveau, programmé manuellement et donc incohérent risque de fonctionner correctement en phase de test mais de poser des problèmes en production. L’automatisation de l’ordonnancement permet d’utiliser une notation et des interfaces similaires pour tous les batch dès les premières étapes, et donc d’effectuer des tests fiables en amont. L’efficacité est encore plus grande lorsque la méthode « infrastructure as code » est employée pour fournir un environnement de test aussi proche que possible de l’environnement de production, ce qui permet d’anticiper et d’éliminer les conflits entre ressources et les incohérences avec les autres séquences.

Faire appel à un système de gestion du code source

Un système de gestion du code source (SCM) – GIT, Subversion, CVS, TFS, etc. – crée un référentiel central pour le stockage des composants applicatifs et la gestion des versions. Un tel système permet de revenir à des versions précédentes, de comparer des versions afin d’identifier les différences et de gérer une dérive éventuelle dans les systèmes déployés. Il fournit également une méthode rapide et fiable pour la compilation ou la recompilation de l’application dans de nouveaux environnements.

Lorsqu’un composant du SCM fait l’objet d’une révision, l’outil de compilation (par exemple Jenkins) reconstruit et teste l’application à la recherche d’erreurs ou pour une régression de fonctionnalités. Typiquement, en cas d’échec d’un test, c’est toute l’équipe de développement qui doit œuvrer à la résolution du problème, ce qui est source de retards. L’utilisation de la méthode Jobs-as-Code réduit naturellement le nombre d’erreurs.

En outre, les applications plus complexes nécessitent un cycle de développement lui aussi plus complexe, englobant souvent le développement, le test, l’intégration, la configuration, le test de préproduction, le test de réception utilisateur (UAT), etc. Lorsque la méthode Jobs-as-Code est combinée avec un SCM et le test dans les phases initiales, une complexité accrue n’aboutit pas nécessairement à un plus grand nombre de défis en aval. Au lieu de cela, les applications arrivent en production avec un maximum de cohérence et de tests. Rendre l’application exploitable dès sa création évite aux équipes de production d’important travaux d’intégration de l’application au sein du SI.

Prendre en compte l’équation de valeur

Pour qu’une application produise un retour sur investissement maximal, le processus de développement doit être aussi optimisé et efficace que possible, et l’application s’exécuter en production avec le minimum de problèmes. La méthode Jobs-as-Code doit désormais être considérée comme un élément essentiel pour la réalisation de ces deux objectifs.

Enfin, n’oubliez pas que même les pratiques de développement les plus rigoureuses connaissent parfois des échecs. Jobs-as-Code ajoute de la visibilité aux applications de sorte que, lorsque cela est nécessaire, les équipes opérationnelles et de support puissent plus rapidement identifier, analyser et résoudre les problèmes afin de rétablir la disponibilité de ces applications. Comme dit le dicton anglais : « fail to prepare, prepare to fail » (« sans préparation, préparez-vous à l’échec »)