BD – Le Déploiement Continu (CD)

Hello !

Lors de la BD précédente, nous avons abordé le sujet de la CI (Intégration Continue). Et impossible de parler de CI sans parler de CD (Déploiement Continu)!

En théorie, la CD implique un déploiement automatique et quasi-systématique de chaque modification du code sur l’environnement de production. Les mises en production sont régulières et ne sont plus une source de stresse, et l’environnement de production est ainsi toujours à jour. En pratique, c’est un objectif très compliqué à atteindre, et pas toujours adapté.

(Petite parenthèse : les bugs ne sont évidemment pas directement corrigés sur l’environnement de recette ou de préprod – on repasse par l’environnement de dev – mais je n’ai pas pu le représenter ainsi dans la BD pour des raisons purement pratiques ^^).

 

 

Pour aller plus loin :

2 commentaires sur “BD – Le Déploiement Continu (CD)”

  • Bonjour, Le "feature flipping" : OK. Mais quelle différence entre les 2 actions suivantes ? - déployer 1000 lignes d'un coup - déployer 100 lignes en 10 fois, mais ne jamais utiliser les 1000 lignes avant d'activer la fonctionnalité Au final, on ne passera vraiment sur les 1000 lignes qu'une fois qu'elles seront toutes déployées et sûrement pas avant. En quoi est-ce que ça aide à détecter les bugs en amont ? Est-ce pour permettre de déployer les autres fonctionnalités / correctifs qui ne seraient pas liés à ces 1000 lignes de code ? Mais dans ce cas, est-ce qu'il ne faudrait pas juste travailler dans une autre branche (si on parle un peu VCS) ? Merci pour vos retours, H.
  • Bonjour, Je pense qu'il y a effectivement plusieurs sujets. L'intérêt du feature flipping, à mes yeux, n'est pas uniquement de debugger : > Tout d'abord, feature-flipper une feature pour la désactiver en production ne signifie pas la désactiver sur les autres environnements. On peut tout à fait - et c'est d'ailleurs l'objectif ! - l'activer sur les autres environnements en amont pour vérifier que tout fonctionne correctement. > Si on reste sur l'idée de détection des bugs, le feature-flipping peut aussi permettre de gérer des canary release : c'est à dire d'activer la fonctionnalité pour une population restreinte d'utilisateurs. De cette manière, on peut tester de nouvelles fonctionnalités délicates sans impacter l'ensemble des utilisateurs (https://blog.octo.com/zero-downtime-deployment/). > Petit bonus : pouvoir activer ou désactiver cette fonctionnalité implique que cette fonctionnalité est correctement isolée du reste du code. Si elle n'est pas isolée et qu'on ne peut pas la feature flipper, c'est sûrement qu'il faut refactorer un peu son code ;) Autre implication : si on l'active et que l'on découvre un bug, on sait exactement à quel morceau de code c'est dû, et on peut y remédier rapidement. > Maintenant, dans le contexte du Déploiement ou de l'Intégration Continus, comme l'objectif en théorie est de déployer son code à chaque commit, le feature flipping est indispensable, notamment dans le cas de features qui prennent plus d'une journée à développer. Le feature branching, qui peut paraître tentant, empêche l'Intégration Continue (article de Martin Fowler : https://www.martinfowler.com/bliki/FeatureBranch.html) > De manière plus générale, comme vous l'avez évoqué, les devs sont souvent sur plusieurs sujets différents, et du coup ça permet de déployer certaines fonctionnalités alors que d'autres ne sont que partiellement terminées. Il y a des features qui peuvent être découpées en plusieurs US, qui ne sont donc pas toutes mergées en même temps. Par exemple, le front est développé, validé et mergé, mais pas le back, mais on ne souhaite pas pour autant ralentir le processus ou le rythme de déploiement. On peut sereinement se permettre de découper les features en US très fines. J'espère avoir répondu à vos questions =) Je vous conseille aussi cet article, qui traite du sujet : https://blog.octo.com/feature-flipping/
    1. Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha