Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Suite à l’un de mes articles sur Azure DevOps Server, il m’a été demandé de faire le point sur les notions d’Update et de Patch. Si vous gérez ou souhaitez héberger votre propre ferme Azure DevOps, il est effectivement impératif de comprendre ces deux notions, et leur impact sur votre plateforme.

Pour être clair sur ce sujet, il faut comprendre ce dont on parle et fixer trois notions :

• - Version majeure : 2019, 2020, ou 2019
• - Update : 2020 Update 1.1, 2002 Update 1.2, ou 2029 Update 1.2
• - Patch : 2022 Patch 1, 2022 Patch 2, ou 2020 Update 1.2 Patch 5.

Note : j’ai volontairement retiré le préfix Azure DevOps Server, afin d’être moins "verbeux".

Implication sur le fonctionnement

Derrière ces trois dénominations se cache en fait la manière dont Microsoft gère les fonctionnalités, et correctifs :

• Version majeure : Ajoute de nouvelles fonctionnalités, peut en déprécier ou supprimer.
• Update : Ajoute de nouvelles fonctionnalités, peut en déprécier.
• Patch : Ajout de correctifs uniquement (résous des problèmes sur une fonctionnalité, ou comble des failles de sécurité).

Avant d’envisager de migrer vers une version majeure, il faut donc toujours commencer par regarder si une fonctionnalité ne disparait pas (Reporting, Build XAML, Services, etc.). Jusqu’ici, Microsoft n’a jamais supprimé une fonctionnalité sans avoir poussé sa remplaçante auparavant. La note de publication des versions majeures permet donc d’être mieux préparé, et de se former en amont sur les nouvelles fonctionnalités.

Attention : Suivez bien les notes des Updates. La connaissance des fonctionnalités dépréciées permet d’anticiper les changements liés aux futures versions majeures.

Implication sur la disponibilité

Effectuer une montée de version, update, ou patch conduit inévitablement à un arrêt de la plateforme. Pour bien planifier cette mise à jour, et diminuer le temps d’indisponibilité, il faut savoir ce que chaque opération induit :

• Version majeure : Corresponds à peu de choses près à une installation. La couche applicative est entièrement réinstallée (Application IIS, Pool, etc.). Les bases de données font l’objet de tests, et d’une migration. Il y a de possibles changements de structures, et l’application de procédures stockées (que l’on peut être amené à relancer si les choses se passent mal. Cas déjà vécu avec TFS 2013).
• Update : Identique à une version majeure.
• Patch : Remplace des binaires, et / ou des ressources utilisées par Azure DevOps.

Le patch est l’opération la plus douce. Elle prend la forme d’une application de type Console très simple. Celle-ci se charge d’arrêter proprement les services Azure DevOps, et de les relancer après l’application du patch. Il n’est donc pas utile d’utiliser TFSSericeControl (d’ailleurs on peut voir les "quiesce" et "unquiesce" dans la sortie de la Console).

L’update est donc une opération longue. Elle peut être aussi stressante qu’une montée de version majeure. Il faut donc toujours avoir un jeu de backup sous la main.

Personnellement, je n’applique jamais une Update sans l’avoir testé sur un serveur créé à partir d’un backup.

Implication sur les montées de version

L’application des Update, et Patchs suit deux règles simples :

• Update : peu s’appliquer à Azure DevOps en sautant des versions majeures ou des updates.
• Patch : ne s’applique que si la version majeure, ou l’update concernée est déjà installée. On peut sauter les patchs inférieurs (le dernier patch contient les précédents).

Si vous utilisez une version 2019, vous pouvez donc directement passer à une version 2020 Update 1.2. Il faudra ensuite appliquer le dernier patch. À savoir : Azure Devops Server 2020 Update 1.2 Patch 5 (voici pourquoi depuis le début de cet article, je ne voulais pas donner le nom complet d’un patch). Ou passer directement de Azure DevOps Server 2019 à 2022, et lui appliquer l’Azure DevOps Server 2022 Patch 2.

Attention tout de même aux releases notes associées aux patchs que vous sautez. Il arrive qu’un patch propose d’effectuer des vérifications, ou des modifications en base de registre (ceci est rare, mais s’est déjà produit pour un patch de la version 2020).

Il faut noter que le patch a l’avantage d’effectuer une petite vérification au début de son exécution. Celui-ci affiche le numéro de version actuelle du serveur. Il affiche aussi le numéro de version du patch, et peut proposer de réappliquer le patch si celui-ci a déjà été installé (une forme de réparation).

Conclusion

J’espère que cet article vous sera utile. Si vous avez des questions, ou besoins d’autres articles comme celui-ci, faites-le savoir via les commentaires, ou un petit mail ;)

C’est toujours un plaisir de rédiger un article pour répondre aux questions d’autres développeurs.

PS: Dans un prochain article, je présenterai une petite simplification apportée par Azure DevOps Server 2022 pour suivre les versions installées.