DEVOPS

« DevOps est un ensemble de pratiques qui visent à réduire le Time to Market et à améliorer la qualité des produits logiciels, en réinventant la coopération entre DEV et OPS. DevOps, c’est un modèle d’organisation, une culture, un assemblage de processus, d’outils et de patterns »

 

Octo Technology, 2018

Disclaimer

L'audit ne couvre pas les dimensions culturelle et organisationnelle de la transition DevOps.

DEVOPS

Accélération du processus permettant d'apporter de la valeur à l'utilisateur

Automatisation

Outillage

Déploiement continu

DEVOPS

Automatisation / Outillage

• La gestion du code source (CI) :
• Le provisionnement des environnements (Infrastructure As Code) :
• La construction des livrables à partir dudit code source (CI) :
• L’assurance qualité du projet (CI)
• Le déploiement des livrables sur un environnement (CD) :

 

• …

DEVOPS

CI / CD

La mise en place de DevOps à la DSI de la ville de Nouméa s’arrête aujourd’hui à l’intégration continue

Intégration Continue (CI)

« 

L'intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l'application développée.

»

 

Source Wikipédia

Intégration Continue (CI)

Intégration Continue (CI)

Objectifs :

• Trouver au plus tôt les éventuels défauts qui existeraient dans le code source,
• Renforcer la propriété collective du code en assurant sa maintenabilité et sa transmissibilité,
• Faire évoluer les standards de codage,
• Faciliter l’apprentissage,
• Améliorer la qualité intrinsèque du logiciel développé
• ...

Points sensibles

• Transition DevOps
  • Point d'arrêt à l'intégration continue (?)
  • Cible (?)

 

 

• Les pratiques et les procédures
  • Culture orale : trop peu de formalisation
  • Homogénéisation nécessaire dans l'utilisation des outils
  • Bonnes pratiques // état de l'art

Structurant

Points POSiTIFS

La transition DevOps est abordée de manière progressive et a permis de mettre en place les premiers éléments de l'automatisation du processus de production logicielle très rapidement.

 

Le fonctionnement de l'ensemble de cette chaine de production est opérationnel et partagé par l'ensemble des collaborateurs.

 

Les équipes travaillent au renforcement continu des pratiques (en cours : testing, logging...)

POUR ALLER plus LOIN...

Il faut envisager de renforcer les pratiques sur :

• des points structurants,
• des bonnes pratiques, et
• d'être vigilant sur des sujets moins impactant.

 

La frontière entre les bonnes pratiques et les points de vigilance peut être ténue. Il revient à la DSI de la Ville de Nouméa de déterminer les priorités qu'elle souhaite adopter en regard des actions proposées.

 

CE qui est structurant

Les points dits structurants sont des points à fort impact sur ce qui est déjà mis en place et dans la perspective de poursuivre l'industrialisation de la fabrique logicielle.

Ils sont au nombre de deux :

• L'utilisation du gestionnaire de code source (SCM), et

 

• l'homogénéisation et le partage des mêmes procédures (déploiement) au plus tôt dans la fabrique logicielle.

SCM

L’utilisation de Git et en particulier le modèle de branches n’est pas clairement défini et les pratiques des développeurs ne sont pas homogènes.

SCM

SCM

La formalisation d'un modèle de branches est structurant dans la mise en oeuvre de la fabrique logicielle par la contextualisation des opérations à déclencher en se rapprochant des différents environnements à adresser :

• développement de nouvelles fonctionnalités  <--> environnements de développement et  d’intégration,
• correction de bugs lors de la recette <--> environnement de qualification, et
• correction de bugs de production <--> environnement de production.

SCM

SCM

Le modèle de branche proposé repose sur le modèle Git Flow et est outillé.

 

Il peut ouvrir des champs supplémentaires d'automatisation de tâches connexes comme :

• Le versionning des livrables sur la base de l'utilisation d'outils complémentaires basés sur Semantic Versionning.
• La constitution du suivi des modifications apportées dans chaque release en s'appuyant par exemple sur Conventional Changelog.
• ...

RECOMMANDATIONS

Homogeneisation

Déploiement des applications

Les procédures de déploiement des applications sont différentes entre le cycle d'intégration et les cycles suivants (qualification et production).

 

Homogeneisation

Déploiement des applications

RECOMMANDATIONS

Les Bonnes Pratiques

L'expression « bonnes pratiques » désigne, dans un milieu professionnel donné, un ensemble de comportements qui font consensus et qui sont considérés comme indispensables par la plupart des professionnels du domaine.

Les Bonnes Pratiques

langages

Utilisation de :

- Java, et

- Kotlin

Même si cela est nativement possible, il faut rester vigilant sur le mixage de ces deux langages pour lesquels l'interopérabilité n'est pas garantie à 100%.

 

RECOMMANDATIONS

Langages

Les bonnes Pratiques

testing

La stratégie de test est actuellement définie comme suit :

 

"(…)

Tests unitaires

• Toutes les méthodes "static public" comprenant des algorithmiques doivent être testées
• Des tests "unitaires" niveau servie peuvent permettre une bonne couverture de code à moindre frais

(…)"

Les bonnes Pratiques

testing

La définition a une portée limitée et le second point contestable. Les tests ne doivent pas être mis en oeuvre en vue d'obtenir un bon score sur un indicateur, mais pour vérifier le bon fonctionnement de l'application.

 

Plus globalement, l'assurance qualité sur l'ensemble d'un projet n'est pas clairement définie (mais il y a des travaux en cours sur la partie testing).

Les bonnes Pratiques

testing

Les bonnes Pratiques

testing

Recommandations

testing

Les Bonnes Pratiques

Apache Maven

Les projets sont pilotés à l'aide de l'outil Maven.

 

Son utilisation peut être renforcée pour :

• la gestion des dépendances (convergence vs. transitivité),
• la séparation des langages (cf. supra), et
• le cryptage des mots de passe utilisés (ZK)

 

Les Bonnes Pratiques

   Apache Maven

RECOMMANDATIONS

Maven

Les Bonne Pratiques

Spring Boot

Ce point est à mettre en rapport aux procédures de déploiement des applications dans les différents environnements et concerne la gestion de la configuration desdites applications d'une part, et l'utilisation des outils de monitoring fournis par le framework Spring d'autre part.

 

Il faut utiliser tous les apports du framework Spring, ici encore avec l'objectif d'homogénéiser les pratiques et de sécuriser les configurations.

Recommandations

Spring Boot

LES Bonnes Pratiques

Java - le type Enumeration

Le choix de la DSI de la ville de Nouméa est de stocker en base les valeurs des énumérations Java et de contrôler au démarrage des applications la cohérence de ces données avec les valeurs de chaque type Enumeration.

 

Il faut noter qu'une méthode de neutralisation de la vérification au démarrage a été mise en place !

 

LES Bonnes Pratiques

Java - le type Enumeration

Cette stratégie, si elle reste possible, est un contresens vis-à-vis du langage Java : "An enum type is a special data type that enables for a variable to be a set of predefined constants.".

 

Elle impose une double maintenance avec d'éventuels redressements de données par l'utilisation de l'ordinal (mécanisme interne au type Enumeration).

 

 

 

Recommandations

Java - le type Enumeration

LEs Bonnes Pratiques

Message de commit Git

Les messages de commit Git ont une importance souvent sous-estimée. Leur rédaction, et surtout leur précision est insuffisamment formalisée.

 

La documentation de l'outil fournit des éléments à mettre en oeuvre dans les messages de commit, et ce même s'il n'y contraint pas.

LEs Bonnes Pratiques

Message de commit Git

Exemple de modèle :

type(subject | scope): short description

 

[ (optional)

Long description

(what & why instead of how)

]

 

[ (optional)

- link to ticketing tool

- breaking changes

]

Recommandations

Message de commit Git

Les Bonnes Pratiques

README.md

Le fichier README est le point d'entrée pour toute personne devant intervenir sur un projet (au même titre que le reste de la documentation).

 

Toute documentation incluse dans le projet doit "vivre" avec le projet.

 

Elle devrait donner des indications telles que :

Les Bonnes Pratiques

README.md

• Le nom du projet
• La description du projet
• Des indicateurs sur le build, la QA, la dernière version disponible, etc.
• Les prérequis techniques du projet
• Les éléments propres au projet et en dehors des standards de la DSI de la ville de Nouméa (architecture applicative, convention de nommage, etc.)
• Les commandes utiles (lancement de l’application, exécution des tests, etc.)
• Un lien vers les spécifications du projet
• Un lien vers l’outil de ticketing
• …

Recommandations

README.md

Les Autres points

Les points suivants, sans minimiser leur importance, sont des points de vigilance.

Langage

 

Version de Java à élever vers la 11 LTS.

Architecture Applicative

Architecture Applicative

Si le modèle en couches de l'architecture applicative doit être mis en oeuvre de manière stricte, il est possible d'en valider le respect par des tests spécialisés (cf. slide sur la partie testing).

RECOMMANDATIONS

Architecture applicative

Base de donnes

Les bases de données de la DSI de la ville de Nouméa sont des bases PostgreSQL.

 

Les tests utilisent une base H2 exécutée en mémoire et en mode de compatibilité PostgreSQL.

 

Il est ici aussi possible de renforcer les tests en vérifiant en préalable à l'exécution d'autres tests que les migrations de bases de données effectuées à l'aide de l'outil liquibase sont opérationnelles.

Base de donnes

L'utilisation de liquibase doit répondre aux règles :

• La granularité des opérations : il faut être le plus unitaire possible.
• L’identification de chaque opération : par un nom significatif.
• L’utilisation des commentaires : pour décrire clairement l’opération.
• Toujours penser aux possibilités de retour arrière (rollback) : en évitant au maximum le sql natif.

Recommandations

Base de données

Environnement de developpement integre (EDI)

Les environnements de développement intégrés permettent de prendre en charge :

- des greffons (plugins),

- des configurations relatives aux conventions et normes de développement

- ...

Recommandations

EDI

Ce qu'il faut retenir

La stratégie de transition DevOps doit être partagée par l’ensemble des collaborateurs. Elle peut être découpée en étapes, chacune d’entre-elles en objectifs si possible timeboxés.

Ce qu'il faut retenir

Les procédures et automatismes déjà en place doivent être revus et corrigés des bonnes pratiques, en particulier dans le processus de développement, dans le but d’homogénéiser ces automatismes et de s’aligner au plus tôt à la cible.

Ce qu'il faut retenir

Les choix effectués, aussi bien dans les pratiques que pour l’outillage, doivent être conduits par les besoins et non l’inverse. Une attention particulière doit être apportée à l’utilisation d’outils en mode SaaS, pour lesquels les évolutions ne sont pas maîtrisées, au regard de la stabilité – et donc de la maîtrise - du processus dans le temps.