En repartant de l’usine de développement tel que nous la connaissons aujourd’hui, nous allons tenter de vous initier à notre vision de l’UDD (Usine de développement) de demain.
En effet, en interne chez OCTO nous travaillons activement sur ce sujet de recherche. Pourtant, avant de rentrer dans les séduisants concepts qu'il pourrait apporter, revenons sur les principes et limites de ce que l’on considère comme une UDD 1.0.
C’est une usine logicielle, contenant des outils pour le développement et permettant d’automatiser tout ce qui peut l’être et ce dans le processus de construction logiciel de bout en bout. Elle joue un rôle important dans l’industrialisation des développements : c’est la clé de voûte de l’intégration continue. Elle permet aussi de construire les livrables sous forme de versions de/des applications.
En effet, le développement logiciel actuel (à l’état de l’art) suit un processus centré sur l’usine de développement. Cela permet de mieux contrôler la qualité des développements et de fournir des indicateurs sur leurs progressions. Nous allons voir comment par la suite. Cette usine de développement se doit aussi d’intégrer tous les outils nécessaires au développement: la documentation, le wiki et le gestionnaire de sources en fait donc partie. Comprenez là qu’il ne s’agit pas d’un logiciel central (type Jenkins), mais d’un ensemble de logiciels branchés entre eux pour faciliter le processus de construction d’applications, depuis le développement jusqu’à la mise en production.
Pour avoir une vision concrète d’une UDD, nous proposons de la représenter schématiquement comme ceci :
On voit ici un workflow plutôt complet et répondant aux besoins de nombreux projets. Cependant, les différentes fonctionnalités sont implémentées en fonction de la maturité et des besoins de chacun.
En préambule de cette question, rappelons la loi du “Defect Cost increase” qui stipule que plus une anomalie est détectée tard plus son coût de réparation est important (on parle d’un facteur de 1 à 1000x). L'intégration continue est une bonne façon de réduire ce risque. Une UDD répond efficacement à cet enjeu en proposant une gestion saine du risque. L’ensemble forme un puissant outil pour le développement et permet d'automatiser différentes étapes :
Elle apporte aussi des bénéfices implicites comme :
Aujourd'hui les usines les plus avancées permettent même le déploiement automatisé et le pilotage des développements à travers celle-ci. On y trouve aussi des fonctionnalités comme :
Bien qu’utilisée en premier lieu dans les équipes de développement, la zone d’influence d’une UDD s’étend à bien d’autres profils. On peut en identifier 4 principaux :
Lors d’un projet d’industrialisation nous identifions plusieurs enjeux et ce à différents niveaux.
Le premier et probablement le plus important, réside du côté de l’automatisation pure et dure du maximum de tâches. Très utilisé dans le développement, c’est aussi un des principaux enjeux de devops car cela permet d’éviter au maximum les erreurs humaines. On prouve rapidement qu’il vaut mieux investir du temps à automatiser tout ce qui l’est, plutôt que passer son temps à rattraper des oublis, des fautes de frappes etc... que nous commettons tous!
Concernant la qualité des développements, on va chercher à améliorer la cohérence et établir des règles et des normes applicables rapidement.
Et enfin au niveau de la production, l’automatisation de la livraison est optimisée pour garantir au maximum la réussite de celle-ci. On a tous connus le “Zut! J’ai oublié de changer telles propriétés dans le 42e fichiers de propriétés de l’environnement prod-18”.
A ce titre, les priorités identifiées concernent aussi bien la gestion du cycle de code source de l’ensemble des applications que le pilotage et le reporting de l’activité. Tout ceci doit nous permettre un Time To Market (TTM) de plus en plus court. Enfin n’oublions pas que l’UDD est aussi très importante pour éviter les régressions aussi bien fonctionnelles qu’en termes de performances. Néanmoins il faut pour cela être capable de tester et mesurer les dérivations liées.
Depuis longtemps dans les DSI on voit des projets de plus en plus gros continuer d’être maintenus. Non content d’être complexes à maintenir ces projets sont souvent très long à faire passer dans le workflow de l’usine de développement. Or plus un projet est gros, plus son potentiel à problèmes est élevé, ce n’est un secret pour personne.
Néanmoins à moins de refactorer tout le code pour permettre la parallélisation des tests avec des outils comme Maven 3, on atteint vite les limites en termes d’amélioration des performances du build. Une limite importante pour obtenir le time to market souhaité est donc ce temps de build (compilation et passages des différents tests et outils de qualimétrie). Nous avons identifié plusieurs autres limites au modèle actuel :
DevOps apporte un ensemble de pratiques qui visent à améliorer la collaboration entre les études et la production, favoriser l’amélioration continue et fait tendre la culture d’entreprise vers la responsabilisation.
Ce mouvement propose des outils dédiés à ces tâches, notamment pour automatiser et mesurer au mieux cette automatisation. D'où l'idée très prometteuse d'une UDD 2.0 en mélangeant cet outillage aux usines de développement actuelles en adressant les enjeux suivants :
Aujourd’hui il subsiste encore de nombreuses étapes manuelles qui pourraient être automatisées grâce aux outils de devops (déploiement de machines, gestion de configuration etc …). De même le passage des étapes manuelles obligatoires (UAT, décision de déploiement etc…) pourrait être facilité grâce aux outils devops.
Très utilisés par les devops les outils de CMDB (Configuration Management DataBase) permettent de centraliser la configuration des environnements, mais aussi de l’intégrer dans l’automatisation des déploiements (on parle ici de déploiement pour passer les différents tests mais aussi pour la production !)
Ces outils ne sont pas seulement une mode, mais les outils de gestion de machines tels que Chef ou Puppets sont non seulement très productifs mais en plus sécurisant. En effet ils permettent d’éviter les « oublis » et erreures humaines classiques lorsqu’on met en place une nouvelle machine. Et pour ne rien gâcher ils permettent surtout de mettre en place automatiquement une machine avec ses packages et la configuration voulue pour y lancer les services voulus. Pourquoi pas une UDD ou une partie de celle-ci… ?
Rien de très nouveau sous le soleil des tests, mais l’intégration d’outils modernes d’instrumentation des tests et de séparations de ces différents tests est un facteur important de nos UDDs.
Pas toujours en place dans les UDD, cette dimension est néanmoins très importante et nous souhaitons la garder en tête pour qu’elle soit pleinement intégrée à nos futures UDD.
Les tests de performances c’est bien, les lancer régulièrement, pour être capable de détecter des dérivations de performance au jour le jour, c’est mieux. Néanmoins c’est souvent très couteux et chronophage. Toutefois, les éléments présentés précédemment devraient permettre de faciliter leur intégration au build.
Un build trop long ? Parallélisons le ou distribuons le sur plusieurs nœuds à la demande. L’idée ici est de réutiliser ce que nous faisons dans nos applications (clustering, distribution de calcul …), pour les construire.
Une fois toutes nos étapes passées, tant qu’à faire déployons en production, nous avons maintes fois prouvés les avantages du déploiement continu.
Avec tout ce que devra gérer cette future usine de développement, il faudra pouvoir retracer son travail pour comprendre pourquoi chaque chose a été faite mais aussi pour pouvoir mettre en place un système d’historisation. Un autre élément important est la capacité de revenir en arrière (rollback) au cas ou le déploiement se passe mal.
En effet il est aujourd’hui problématique de gérer un SI multi-technologies : applications Java, .NET, iPhone, Windows Phone… chacune veut sa plateforme pour builder hors cela va à l’encontre de notre volonté de mutualiser l’UDD au maximum…
Voilà vous avez maintenant une petite idée de ce que nous cherchons à mettre en place dans nos UDDs.
La suite au prochain épisode... stay tuned !