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".

Les différentes évolutions d’Azure Pipeline ont amené beaucoup de bonnes choses. Dont une belle simplification de la gestion des stratégies de rétention des builds. Mais ceci est arrivé avec un petit effet de bord : des pipelines qui ne disposaient pas d’une stratégie de rétention voient leurs exécutions affublées d’un bail "Legacy Retention Model".

La problématique

Le bail "Legacy Retention Model" interdit la suppression des exécutions.

Aucune stratégie n’étant définie avant l’évolution de cette fonctionnalité, Microsoft ne peut pas prendre la décision de supprimer des exécutions à notre place. La démarche est donc logique.

Pour pourvoir supprimer les excitions concernées, il faut donc retirer les baux. Cette opération peut être fastidieuse si vos avez beaucoup de pipelines, projets, ou organisation / collections.

Voici une information qui fait rire un peu jaune dans le petit monde « on-premise ». À la sortie de Visual Studio 2022, il y avait un petit problème de support par Azure DevOps Server. Les pipelines ne permettaient pas d’utiliser les build tools de Visual Studio 2022 simplement. Il y a un an, je publiais un article expliquant une méthode de contournement simple (disponible ici). Par la même occasion, je déconseillais de tenter d’installer des tâches customisées. J’espérais alors que celle-ci arrive rapidement via une mise à jour.

Uptate 2022 ou Patch?

La sortie d’Azure DevOps 2022 en décembre dernier refaisait vivre cet espoir. Pourtant, le support tant espéré n’était pas de la partie.

Surprise, surprise ! Le patch de février ajoute les tâches MSBuild et VSBuild détectant automatiquement VS 2022. Il s’agit là d’une grosse surprise. Il n’est pas habituel que Microsoft ajoute de nouvelles fonctionnalités via un Patch. Cela a généralement lieu lors d’une Update. Il y a fort à parier que l’équipe Azure DevOps ait considéré l’absence de ces taches comme étant une erreur.

Il n’est pas fait état des tâches de tests. J’espère qu’elles sont mises à jour par la même occasion. Je vérifierai dans les prochains jours si ce n’est pas le cas.

Conclusion

Maintenant, on peut considérer que le support de VS 2022 est équivalent pour les versions Cloud et On-premise d’Azure DevOps. La nouvelle est rassurante, car il n’était pas courant que Microsoft prenne autant de temps pour rendre iso les deux versions.

La mise en place d’une démarche DevOps efficace passe toujours par l’utilisation d'outils de monitoring. Sur Windows, quelle que soit la solution retenue, celle-ci aura besoin de compteurs de performances (ou alors, le monitoring sera très limité).

La problématique

Pour ne pas être noyé dans la masse des métriques, il faut savoir identifier les compteurs utiles, et ceux qui sont disponibles sur les serveurs. Si Microsoft Learn fournit beaucoup d’information sur les compteurs de performances, il est toujours difficile de savoir ceux qui sont vraiment utilisables localement (et pourquoi certains outil ne trouvent pas certains compteurs).

Si vous développez des applications pour Fitbit OS, vous avez reçu ce soir un mail peu agréable. Fitbit y annonce la fermeture prochaine de son service Fitbit Studio. La fermeture se fera en deux étapes :

• 20 mars 2023, le service passe en lecture seule.
• 20 avril 2023, le service ferme définitivement ses portes.

Non, vous ne rêvez pas. Vous avez deux mois pour récupérer vos projets. Après il sera trop tard. C’est ce que nombre de personnes appellent la méthode Google. Je ne suis pas franchement fan.

Pour ceux qui ne connaitraient pas Fitbit Studio : il s’agit d’un site web permettant la création d’applications pour Fitbit OS. L’outil fournit tout le nécessaire pour créer, éditer, compiler de stocker ses projets.

Tout n’est pas encore perdu?

Bien évidemment, le développement d’application reste possible. Fitbit oriente les développeurs vers son SDK (utilisable avec VS code et node.js).

Pour les développeurs professionnels, la fermeture de Fitbit Studio est anecdotique. Elle arrive cependant dans un contexte peu encourageant :

• Fitbit coupe des fonctionnalités de sa propre application (disparition des challenges entre amis).
• Le dernier SDK date d’il y a un an et demi et n’apporte pas grand-chose.
• Les dernières montres sous Fitbit OS datent d’il y a un peu plus d’un an et n’apportent pas de nouveautés.
• Aucune mise à jour n’est apportée aux montres existantes.

La seule véritable nouveauté chez Fitbit depuis son acquisition par Google il y a deux ans, est une montre qui n’est compatible qu’avec Google. Celle-ci n'a pas convaincu la presse, et ne semble pas non plus avoir trouvé ses utilisateurs.

Conclusion

Autant dire que je ne suis pas confiant concernant l’avenir de Fitbit by Google. J’étais beaucoup plus fan de « Fitbit tout court », plus ouvert, plus dynamique, plus actif, et beaucoup plus prévenant envers ses développeurs, et utilisateurs.

La suite au prochain épisode. J’espère qu’il ne sera pas annonceur d’une nouvelle fermeture de service, ou de la fin d’un support.