Quels sont les moyens de dissocier le déploiement de la version?

Une méthode de déploiement continu consiste à dissocier le déploiement de la version, c'est-à-dire de déployer les mises à jour sans activer immédiatement les modifications.

Je sais que les fonctions-bascules peuvent être utilisées pour cela, mais je me demande s'il existe d'autres techniques pour les "non-fonctionnalités".

Par exemple, voulez-vous créer une bascule de fonctionnalité pour un correctif? Probablement pas et on pourrait faire valoir que les corrections de bogues devraient être déployées dès que possible, car cela ne peut que s'améliorer. Et après la publication d'un correctif, je ne veux plus le désactiver. Mais est-ce le cas? Il peut s'agir d'un changement risqué que vous souhaitez publier de manière contrôlée. Et s'il y a des effets secondaires inattendus, il est bon de pouvoir rouler en arrière. Alors, des drapeaux pour chaque changement?

Et qu'en est-il des changements visuels? Par exemple, pouvez-vous implémenter quelque chose comme un indicateur de fonctionnalité en CSS? Est-ce même logique?

Pour les logiciels de la catégorie des applications Web, selon votre infra / fournisseur d'hébergement, un tel découplage peut être possible pour basculer le trafic entrant sur (ou le répartir entre) différentes versions déployées de la sw, couvrant pratiquement tous les changements que vous mentionnez: corrections de bugs, visuels , etc.

Un tel support ne nécessiterait généralement pas de bascule de fonctionnalité. Et cela peut être applicable quelle que soit l'application qui soit monolithique ou divisée en microservices.

Par exemple, l' offre App Engine Paas de Google prend en charge la répartition et la migration du trafic.

Du fractionnement du trafic :

Vous pouvez utiliser la répartition du trafic pour spécifier une répartition en pourcentage du trafic sur deux ou plusieurs des versions d'un service. La répartition du trafic vous permet d'effectuer des tests A / B entre vos versions et de contrôler le rythme lors du déploiement des fonctionnalités.

Depuis la migration du trafic :

La migration du trafic bascule le routage des demandes entre les versions d'un service de votre application, déplaçant le trafic d'une ou plusieurs versions vers une seule nouvelle version.

Alors qu'avec les monolithes, vous pouvez être limité aux commutateurs, avec les architectures de microservices, vous pouvez fractionner chaque pool de déploiement de nœuds fournissant un service (c'est-à-dire des pods). Vous activez ensuite le déploiement du produit nouvellement modifié dans un sous-ensemble de pool et le surveillez attentivement; vous pouvez même choisir le montant du pool sur lequel déployer la modification, par exemple, activer la modification pour 15% du trafic. Vous pouvez trouver la fonctionnalité appelée «mise à jour continue» dans la littérature.