Upgrader un serveur transactionnel Open Suse vers Leap 15.4

La configuration d’Open Suse en mode serveur transactionnel a beau avoir la côte depuis quelques années, certains scénarios ne sont pas toujours documentés. C’est le cas du processus d’upgrade vers Leap 15.4.

Sur un serveur en mode transactionnel, une partie du système est en lecture seule. L’administrateur doit donc apprendre à jouer avec la commande transactional-update.

Si vous suivez la documentation officielle, il y a un blocage au moment de rafraichir la liste des repositories (étape 6), puis lors du lancement de la mise à jour (étape 7). Transactional-update ne dispose pas d’options pour reproduire ces commandes.

Comment bien choisir ses dépendances (librairies, modules, etc.) ?

Quel que soit le type d’application à réaliser, ou la technologie employée, le choix des dépendances est critique. Certaines peuvent vous simplifier la vie aujourd’hui et la transformer en véritable cauchemar à long terme.

Je vous propose aujourd’hui de présenter quelques points à ne pas négliger au moment d’effectuer ce choix.

Identifier des failles de sécurité avant même de pousser son code dans Azure DevOps

Nombre de développeurs utilisent des builds afin d’anticiper de potentielles failles de sécurité. Je ne suis pas franchement fan de ce genre d’approche. Soit la build interdit le commit ou le merge, soit les développeurs doivent consulter les rapports de builds. De plus, si la build est longue cela peut pénaliser les développeurs.

Pour les développeurs .net, il existe une solution simple, rapide et efficace. Il suffit d’utiliser Code Analysis avec Security Code Scan. Après installation du package Nuget de Security Code Scan, Visual Studio vous avertira du moindre problème de sécurité (code potentiellement dangereux, mauvaises pratiques, etc).

Security Code Scan peut être utilisé via une build Azure Pipeline ou en ligne de commande. Je préfère cependant l’utiliser via Nuget. Cela me permet d’identifier une faille de sécurité avant même d’avoir fini l’édition de mon code. Je ne risque donc pas de pousser un code faillible.

Jérémy Jeanson

Pourquoi continuer de payer pour générer des MSI ?

Encore aujourd’hui, beaucoup d’entreprises font l’acquisition de solutions couteuses pour la génération de leurs MSI. En général, la facture s’élève à quelques milliers d’euros pondérés par le nombre de développeurs, et d’agents ou de serveurs de builds. À la fin de l’année, la facture peut être salée.

... Et si je vous disais que je n’ai jamais payé ni fait payer à mon entreprise ce type de produit ?

Comment un simple using ou imports peut vous compliquer la vie ?

Chaque évolution de .net, apporte son lot de nouvelles syntaxes pour C# ou VB. Parmi celles-ci, il en existe certaines qui peuvent vous compliquer la vie. Je vous propose aujourd’hui de décortiquer une syntaxe destinée à nous aider : "using static". Vous découvrirez les soucis qui peuvent en résulter et les dangers auxquelles celle-ci vous expose.