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.

Mais c’est quoi une UDD ?

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.

A quoi me sert mon UDD et qu’apporte t’elle ?

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 :

• Le “checkout” du code de référence et implicitement renforce l’usage d’un gestionnaire de sources professionnel
• La compilation du code
• L'exécution des tests automatisés
• La mesure de la couverture de tests et de la qualité du code
  • Le respect des standards de développement
  • La bonne utilisation des designs patterns
  • La Conformité aux règles d’architecture

Elle apporte aussi des bénéfices implicites comme :

• La mise à disposition pour les membres non techniques d’indicateurs compréhensibles sur le process de développement, la progression et la qualité.
• L’amélioration continue de la qualité du code et une plus grande confiance dans le code produit.
• L’amélioration de la productivité pour les équipes de développement

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 :

• La génération de site de reporting technique et (par exemple avec Maven site)
• Le pilotage et le reporting de l’activité des équipes de développement grâce à l’affectation des tâches ou le suivi des corrections des bugs.
• Le packaging pour les plateformes de test et production
• Le déploiement vers les différents environnements (voir https://blog.octo.com/5-bonnes-raisons-de-deployer-en-continu/ )

À qui s’adresse mon usine ?

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 :

• Le “métier” : On déploie plus souvent et donc on peut tester plus régulièrement. L’usine met aussi à disposition des outils permettant le feedback sur le logiciel en cours d’élaboration.
• Le tech lead (ou chef de projet ?) : Il suit les métriques de qualité et dispose d’outils communs avec les équipes de développement.
• L’équipe de production (les Ops) : Elle est en charge du bon fonctionnement de l’usine et participe activement à la phase de déploiement.
• L’équipe de développement : Elle produit le code et l’usine permet d'automatiser les étapes du build.

Quels sont les enjeux ?

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.

Quelles sont mes limites ?

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 :

• Le déploiement continu (a ne pas confondre avec la livraison continue) : de nombreuses usines de développements actuels sont déjà utilisées pour faire du déploiement continu. Néanmoins on est souvent amenés à coder son script de déploiement maison et à le faire appeler par l’usine.
• La gestion multiplateformes - de la plateforme mobile au .Net en passant par Java : impossible de builder du code .NET ou iPhone sur un environnement linux.
• Le déploiement de l’ensemble de notre UDD sur le Cloud est loin d’être trivial et reproductible , même si des usines  dans le Cloud existent.
  • On peut même imaginer vouloir générer une UDD complète en fonction de la typologie du projet (Java ou iOs).
  • Ces UDDs ont besoins d’être adaptables et multi projets, on ne peut pas envisager une UDD par projet, il est nécessaire de les mutualiser. Si 10 projets impliquent 10 UDD les coûts de maintenance des UDDs vont vite exploser.
• Le monitoring  - Par exemple suivre le TTR (Time To Resolve) en temps réel.
• La gestion d’un build incassable, déjà adressable par une UDD 1.0 mais un incontournable dès lors qu’on souhaite faire du déploiement continu.
• La distribution du build, sur plusieurs nœuds ou même simplement la parallélisation de certaines étapes sur un seul noeud. Bien que possible sur certaines plateformes cela s’avère encore complexe à mettre en œuvre, ce serait pourtant un bon moyen d’accélérer les temps de build. En effet plus le build sera rapide à passer, plus on pourra avoir les résultats et métriques souhaités, et plus on pourra décider d’un déploiement en production rapidement (Time to market quand tu nous tiens …)

Vers une UDD 2.0, le mouvement DevOps comme fer de lance

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 :

• Améliorations de la gestion des Workflows de build

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.

• Gestion des environnements

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 !)

• Mise en place des plateformes

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… ?

• Test automatisés (unitaires, recettes, intégration, …)

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.

• Qualité logicielle

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.

• Détection de dérivation de performances

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.

• Rapidité d'exécution :

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.

• Déploiement continu vers la production

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.

• Audit

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.

• Et enfin l’aspect Multilangages

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 !