vendredi 22 mars 2019

Retour sur les Devopsdays Geneva

Nos experts nous font part leur expérience aux Devopsdays

 

 

Les premiers DevOpsDays à Genève qui ont eu lieu les 21 et 22 février ont été un succès retentissant avec plus de 270 participants, plus d’un million de sourires échangés et plus d’un milliard d’idées partagées.

 

Nos experts étaient présents et reviennent sur cet évènement afin de nous faire part leur expérience :

3 grands types de conférences autour de Devops:

  • Approche/Méthodologie
  • Retours d'expérience en entreprise
  • Outils / workshop

 Démocratisation des pipelines

 

Dans l'intégration continue (CI), la notion de pipelines est maintenant complètement adopté par la communauté.

La tendance est maintenant à leur optimisation par la mise en place de cache pour éviter de tout refaire à chaque fois. Cela s'explique par 2 facteurs :

 

- Fort de son succès, le processus de CI devient de plus en plus long. Or un de ces objectifs est d'avoir un retour le plus rapidement possible (< 5 minutes) car en cas de problème, le coût de la correction est inversement proportionnel au temps nécessaire à la détection du bug.

 

- Le Cloud, avec sa facturation à la consommation, est de plus en plus au cœur de notre chaine de production. Aussi notre intérêt est d'optimiser au maximum l'intégration afin de diminuer les coûts

 

Montée en puissance de l'outil GitLab

 

Nous connaissons tous l'outil Gitlab depuis plusieurs années maintenant. Mais ce qui n'était au départ qu'un gestionnaire de source "on premise", est devenu une véritable chaine de production permettant de gérer toute la chaine Devops tout en gardant une bonne flexibilité. L'avantage par rapport aux chaines plus traditionnelles, que ce soit des suites d’outils (Jira, git, Jenkins, etc…) ou usine ALM (Jazz, TFS, etc…), est que nous sommes dans une forge flexible bien plus complète et adapté à Devops que les premières forges type redmine.

 

Testing

 

Après 20 ans d'évangélisation sur le TDD, la pratique du test est bien entrée dans les mœurs: plus un projet qui ne parle pas de test.

Le nouveau cheval de bataille est maintenant le BDD: l’objectif est de décrire les cas d'usage dans un langage naturel permettant leur exécution. Ainsi nos stories sont décrites sous cette forme. L'intérêt est que la validation se fait par l'exécution de ces cas d'usage c’est-à-dire, que nos spécifications sont maintenant des tests. Cela évite de nombreux écueils dans la façon d'écrire les stories et les critères acceptation. Maintenant les critères peuvent se résume à : si les cas d'usages décrivant la story s'exécute dans problème, la story est validé.

Maintenant même si nous connaissons quelques projets qui pratiquent cette approche, il reste encore à acquérir beaucoup de maturité pour l'automatiser dans tous les projets.

 

Sécurité

 

Devops n'échappe pas à la tendance sécuritaire avec des sujets comme le DevSecOps. Cela est logique pour plusieurs raisons:

 

L'objectif de Devops est de faire travailler ensemble les développeurs et les opérationnels. Or en tant que développeur, une bonne partie de la sécurité (nous ne parlons pas que de l'authentification et des autorisations...) a souvent été de la responsabilité des équipes d'infrastructure. Aujourd'hui, ces équipes de développement doivent prendre conscience que nous ne pouvons plus nous reposer sur les équipes infra: cela est maintenant notre responsabilité. Les fournisseurs de cloud font très bien passé le message avec la notion de sécurité partagée (https://aws.amazon.com/fr/compliance/shared-responsibility-model/).

 

La gestion des dépendances a toujours existé que ce soit au sein des équipes de développement avec les gestionnaires d'artifact (maven, nugget, npm), ou au sein des équipes d'infrastructure avec les gestionnaires de dépendances (rpm, dpm, ...). Mais aujourd'hui avec le Devops nous avons franchi une étape. D'abord avec le partage d'un répertoire commun (docker image) et ensuite avec des lifecycles de plus en plus court qui favorisent l'émergence du risque d'injection de code malveillant dans des dépendances externes. Ainsi il faut renforcer nos processus et nos outils pour prendre en compte ces risques.

 

Monitoring

 

Dans la logique de l'amélioration continue, tout le monde est aujourd'hui conscient que pour s'améliorer il faut se mesurer! Aussi beaucoup de sujet autour du monitoring.

Encore faut être capable de rendre ces métriques disponibles dans un format lisible pour le plus grand nombre (ne pas oublier les équipes métiers).

 

Pour cela on travaille sur différents axes:

 

- Représentations graphiques parlantes (gauge, graph, heat map etc).

- Agrégation des données afin de sortir des représentations plus complexes (comportement des utilisateurs).

- Mise en place des alertes sur certains événements (par exemple : pic de connexion –> email d’alerte)

Il est aussi nécessaire de définir des politiques de rétention de ces données car il est rarement nécessaire de conserver des années de métriques.

 

Pour la mise en place de tout cela, le couple Prometheus (base de données orientés métriques) et Grafana (“générateur de graphs") sont leaders sur le marché (deux outils open source).