Chaque nouvelle année débute avec son lot de bonnes résolutions plus ou moins difficiles à tenir. Et si cette année, vous vous concentriez vos efforts sur :

• Votre code ?
• La qualité de celui-ci ?
• Sa maintenabilité ?
• Sa capacité à évoluer ?

Pas facile de choisir, et encore moins de tenir ces objectifs dans le temps.

Histoire de vous encourager, je vous propose d’installer l’extension NDepend sur Azure DevOps (ou GitHub).

Vous pourrez alors disposer d’un Dashboard NDepend intégré à Azure DevOps dont les métriques évolueront au fil du temps et de vos builds.

Vous aurez alors plus de facilité pour choisir, prioriser, et tenir vos bonnes résolutions dans l’année.

Pour vous lancer, je vous encourage à vous rendre sur cette page.

Dans les prochains mois, je détaillerai mes usages (plein de bonnes choses à venir).

Voici une petite ligne de commande qui peut vous faire gagner beaucoup de temps lorsqu’il s’agit de résoudre les problèmes de connexion d’un utilisateur.

Get-WinEvent -LogName Security | where-object  { $_.Message -like '*jeremy*' } | Select -First 10

Note : penser à remplacer "jeremy" par le login de l’utilisateur concerné.

Celle-ci vous retournera les informations d’audit relatives aux dernières sessions d’un utilisateur. Étant donné qu’il s’agit d’une commande PowerShell, elle peut être exécutée à distance (ce qui fait gagner beaucoup de temps). Vous pouvez alors établir la date et l’heure exacte à partir de laquelle votre utilisateur n’a plus été en mesure de se connecter et remonter l'historique des actions entreprises depuis.

De base, les agents de build hébergé par Microsoft n’incluent pas le JDK 19 d’Oracle (depuis le passage à Open JDK, il n'y a plus de support des nouveaux JDK d'Oracle). Si vous voulez à tout prix reposer sur celui-ci, il reste alors deux solutions :

• Modifier la build afin d’inclure des tâches de téléchargement et d’installation du JDK.
• Héberger son propre agent et y installer le JDK.

La première approche est la plus rapide à mettre en place. Cependant, celle-ci allonge la durée de la build.

Si vous avez besoin de builds rapides, la seconde option est préférable. Je ne vous cache pas qu’il s’agit de mon approche préférée. Les agents sont plus rapidement disponibles. Ils peuvent profiter du cache de précédentes builds (binaires générés, code, et dépendances téléchargées).

Voici une situation qui peut très vite devenir irritante : vous avez développé plusieurs applications web dans un même repository Azure DevOps (dans mon cas : Blazor, et WebAPI). Vous souhaitez les publier via Azure Pipeline. Vous utilisez donc le template .net core par défaut et y ajoutez une tâche DotNetCoreCLI@2 avec la commande publish. Cependant au moment de consulter les artefacts produits, vous vous rendez compte qu’une seule application est présente.

Chaque nouvelle version de .net arrive avec son lot de rumeurs et d’idées reçues. Dernièrement, j’ai lu sur Reddit qu’il était impossible de migrer de .net framework vers .net 7. Jouant avec .net depuis ses débuts, je suis choqué par cette affirmation sans véritable fondement.

Heureusement, cela n’est pas vrai.