Comme je l’avais déjà expliqué l’an dernier, je ne suis pas fan des scripts PowerShell signés. Ceux-ci donnent un faux sentiment de sécurité. Dernièrement, je suis tombé sur une situation qui a anéanti le peu de bien que je pouvais en penser.

Il se trouve qu’un script signé a une limitation qui n’est pas visible de premier abord. Passé la date de validité du certificat qui a servi à la signature, le script n’est plus utilisable. Oui, vous lisez bien. On ne peut plus exécuter le script. Quand on en utilise beaucoup, ce n’est pas terrible (vraiment pas).

Cela fait des années que je signe des binaires, des msi, ou du ClickOnce. Après expiration des certificats, je n’ai jamais rencontré de problème d’exécution, ou de déploiement. Les fichiers signés restent utilisables malgré l’expiration du certificat qui a servi à les signer. Je ne m’attendais donc pas à un tel comportement.

Moralité

PowerShell, c’est génial. Je ne saurais plus vivre sans. Mais la signature des scripts est un véritable enfer dans lequel il est préférable de ne pas mettre les pieds. Ou alors, il faut être vigilant sur le contenu des scripts signés. Il faut aussi faire attention au fait que la signature implique que ceux-si ont une date limite d'utilisation.

Si demain je dois à nouveau signer un script, et le distribuer, mon premier reflex sera d’ajouter dans celui-ci un commentaire indiquant la date de péremption de son certificat.

Autrement dit, je distribuerai des scripts avec une date limite de consommation.

La dette technique est un sujet difficile à traiter. Nombre d’éléments peuvent compliquer les choses :

• Technologies.
• Dépendances.
• Domaines fonctionnels traités.
• Criticité de l’application pour les utilisateurs.
• Coût.
• Temps.
• …

Il peut y avoir aussi quelques soucis d’ordre "culturel" (autre manière de ne pas dire "politique") :

• Désintérêt pour les aspects techniques.
• Manque de motivation.
• Peur des régressions.
• …

Même si ce n’est pas facile, tout le monde peut surmonter ces problèmes, et résorber sa dette technique. Cela ne se fera peut-être pas rapidement. Il est préférable de l’accepter. Le jeu en vaut la chandelle.

Mais il est des situations qui peuvent compliquer les choses de manière irrémédiable. Je me propose de vous présenter ici trois cas réels, et vécus en ESN (à l’époque, on disait SSII, mais je m’adapte). Soyons claires tout de suite. Aucune des situations présentées ici n’est liée à mon emploi actuel, et j’en suis fort heureux. Travaillant aujourd’hui pour un éditeur, je crois que j’aurai beaucoup de mal à les vivre à nouveau. Contrairement aux éditeurs, les ESN ne sont souvent que "de passage" sur une application. Les développeurs / consultants qui assurent une mission à un instant T vivent donc "différemment" la dette technique. Personnellement, je n’ai jamais bien vécu cette expérience, et encore moins le fait que l’on me demande de la faire passe sous le tapis. C’est tabou. Il ne faut pas en parler au risque de déplaire au client. Bêtement, j’ai toujours pensé que le client adorerait qu’on lui remette un rapport sur celle-ci. Une ESN plus futée se rendrait peut-être compte que le sujet peut apporter d’autres prestations.

Cela fait maintenant quelques années que je ne travaille plus dans le domaine du conseil. Je vais pouvoir commencer à me lâcher un peu, sans qu’un client ait l’impression d’être l’objet d’un article.

Pas de panique, il ne s’agit pas d’un changement de ligne directrice de ce blog. Je reste sur les lignes originelles de ce blog : du .net, de la Tech, un côté geek assumé, et toujours une petite dose d’humour. Je vais juste m’autoriser à discuter de sujets plus "sensibles".

Je débute donc une nouvelle série d’articles sur quelques "tabous" des métiers de l’IT, du Dev, et des ESN.

Au plaisir de lire vos commentaires, et mails sur ces sujets ;)

Effectuer la mise à jour d'une ferme Azure DevOps peut prendre un peu de temps. Cela dépend de l'infrastructure, du nombre de collections à migrer, de la taille de celles-ci, et aussi du support utilisé pour la migration.

Depuis quelques années, Microsoft a mis à disposition des exécutables pour installer Azure DevOps (exécutables de type Web Installer, comme pour Visual Studio Installer). Ceux-ci sont un peu trop mis en avant à mon goût.

Jusqu'ici, identifier la version d'Azure DevOps Server installée n'était pas facile. On pouvait obtenir un numéro de version majeur, et c'était tout. Sachant qu'il n'existe aucune documentation résumant les numéros de version, l'intérêt est limité.

Encore aujourd'hui, si on ouvre une console d'administration d'Azure DevOps Server, on obtient une information limitée.

Sur le détail de la couche applicative configurée, l'information est similaire :

Ceci n'est pas très parlant.

Heureusement, il existe une page "À propos" sur le portail web. Celle-ci est disponible via le lien suivant : https://mon-nom-dns/tfs/ma-collection/_home/about . Depuis Azure DevOps Server 2022, on peut y lire la date du patch appliqué et sa version. Enfin une information facilement exploitable!

Ma capture d'écran date un peu. En l'occurrence, il s'agit du premier patch publié après la sortie de DevOps Server 2022 en décembre 2022.

Pour rappel, avant Azure DevOps Server 2022, la page ressemblait à ceci: