Dans le cadre d’un environnement de “delivery” agile, il est important d’être réactif sur les cycles de vie des applicatifs ainsi que sur leur initialisation.
L’offre des outils permettant de gérer l’intégration et le déploiement continu est de plus en plus fournie (il serait quasi-impossible de tout recenser !), les DSI des grands groupes (principalement), tentent d’abstraire cette complexité en rendant la création des pipelines CI/CD le plus générique possible.
On cherche alors à mutualiser le plus possible, afin d’accélérer au démarrage et faciliter la gouvernance. Mais ces outils tiennent-ils vraiment toutes leurs promesses ? À quel prix ?
Il s’agit d’une application centralisant les différentes étapes de création de projet. Via un formulaire, le projet est généré automatiquement suivant différentes étapes :
L’idée générale étant d’accélérer la phase d’initiation du projet et de démarrer les cycles de développements le plus rapidement possible !
Dans les solutions éditeurs, nous pouvons parler de Backstage de Spotify.
Backstage est un catalogue de composants SI à destination des équipes de développement. Ce genre de portail permet entre autres d' automatiser la création de nouvelles applications (base de code, pipelines CI/CD, repository GIT …).
Azure Devops va également générer tous les éléments nécessaires à du packaging et du déploiement utilisant les composants Azure.
AWS Code Pipeline automatise aussi la création de projet à disposition des développeurs utilisant les composants AWS.
Un projet “sur les rails” dès le début : un simple formulaire à remplir et après quelques “clics”, tous les dépôts et pipelines sont créés, l’application est initiée. Les développeurs n'ont plus qu’à coder.
Un workflow et un code conformes aux normes de la DSI (sécurité, choix technologiques, étapes de CI/CD…) dès la première itération.
Une impression à court terme de time to market accéléré : dès lors que le projet est généré, les développeurs peuvent se concentrer sur le code métier, ayant une plus forte valeur ajoutée.
Mais gare au moment où il faudra sortir du chemin tracé… !
Perte de la culture CI/CD : les développeurs n’ont pas toujours conscience des rouages sous-jacents. Et abstraire tout cela ne va pas les aider ! Lorsque quelque chose se passe mal, ils ont plus de difficultés à investiguer les causes du problème. On ne maîtrise réellement que ce que l’on a participé à concevoir.
Une pratique qui va à l’encontre du “You build it You run it” (celui qui conçoit, c’est celui qui opère) : qui, mieux que les développeurs, sont les plus à même de déployer une application ?
Perte de responsabilité : on entend encore trop souvent le fameux “ça marche en local” lorsque l’application ne se déploie pas en production. Tout comme les points précédents, lorsque l’on ne participe pas à la conception d’un système, il est très difficile de se sentir concerné par le fonctionnement de celui-ci. Cela est d’autant plus vrai si l’on n’a pas effectivement la main pour modifier ou adapter ce système.
Un outil de moins en moins générique : chaque projet à ses spécificités et doit par conséquent les répercuter sur le portail. La promesse du “one size fits all” est ici mise à mal. Ce qui au début part d’une bonne intention (gouvernance, rationalisation …) finira au final par devenir un carcan, qui ne pourra que freiner l’innovation.
Il sera nécessaire de réaliser une étude pour savoir si le projet est “éligible ou pas”, ou il faudra le temps que l’équipe en charge du portail intègre les spécificités du projet, ou encore il faudra concevoir un process pour obtenir une dérogation...
Coût de maintenance : Le backlog du portail, s' il est développé en interne, est de plus en plus fourni en demande de fonctionnalités spécifiques. L’équipe en charge du portail passe de plus en plus de temps à gérer ces demandes et le produit perd petit à petit en maintenabilité.
Comment anticiper le risque ?
Actions à mener :
Le diagramme ci-dessous reprend les actions à mener dans le cadre de la CI/CD selon deux critères :
Selon ces deux critères, nous trouvons les actions suivantes :
Quels enseignements en tirer ?
Les différents éléments étudiés montrent les limitations d’un portail d’amorçage projet. Ces limitations se rapprochent de ce que l’on peut trouver sur un PaaS : force à respecter les bonnes pratiques, aide à la standardisation, mais dès lors que l’application ne rentre pas dans le moule, les problèmes arrivent !
Les applications plus spécifiques risquent alors de s’éloigner du portail, engendrant des risques de”shadow IT”. En même temps, l’équipe dédiée au développement du portail tente de rattraper son retard vis-à-vis des applications spécifiques, ce qui a de fortes chances de complexifier l’outils (plus de champs à remplir, un backlog qui s'alourdit …).
Masquer la mécanique peut nuire à la compréhension des mécanismes sous-jacents et entraîner une perte d’autonomie et de maturité au sein des équipes par rapport aux standards et évolutions du marché. Il faut donc encourager les équipes à s’impliquer dans la conception de cette solution.
Ainsi, l’effort d’amorçage d’un projet profitera à tous et le portail sera un catalogue enrichi par ses utilisateurs, plutôt qu’un cadre rigide imposé par la DSI.
Mais “ne jetons pas le bébé avec l’eau du bain”. Ces portails, s’ils sont à la main des équipes qui l'utilisent, peuvent avoir une grande valeur ! De même, pour un projet “standard”, il n’y a pas de raison de s’en passer ! Il remplit alors ses promesses, d’accélérateur de projet, sans pour autant responsabiliser vos équipes !