Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
1676 connectés 

  FORUM HardWare.fr
  Programmation
  C#/.NET managed

  Versionning de projets .NET pour exploitation externe

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Versionning de projets .NET pour exploitation externe

n°2338549
DiB91
Bwaaaaaaah
Posté le 30-08-2019 à 17:40:06  profilanswer
 

Bonjour par ici :)
 
Aujourd'hui, j'ai une petite question sur laquelle je sèche, probablement de par l'aspect spécifique du truc...
Peut être que vous, la famille HFR, avez déjà été confronté à un cas comme ça ? :jap:
 
Je bosse au boulot sur une solution contenant une 40aine de projets, donc 5 applications web écrits dans des langages différents.
Habituellement, on livre ces applications un peu à l'arrache, via MS Deploy sur le serveur IIS de prod, après avoir fait des ZIP de backup des binaires actuels...
Suite à un crash serveur un peu violent, l'infra souhaite que nous mettions en place un versionning de nos binaires quand on les livre.
 
L'idée c'est que mes collègues à l'infra puissent récupérer un numéro de version pour chacun de mes projets, pour savoir s'ils doivent inclure le dossier de l'appli dans les backups quotidiens, ou pas.
Ils disposent de PowerShell pour les y aider, donc ils sont assez limités (lecture d'un fichier texte, retour d'exécution d'un petit .exe ....).
Ils ne peuvent *pas* exécuter de script SQL pour récupérer la version déployée en cours.
 
Je suis obligé d'utiliser les mécaniques natives à .NET parce que les projets sont tellement hétéroclites qu'il faudrait développer ou installer un truc différent pour chaque projet... c'est pas envisageable.
Je pensais donc m'appuyer sur les AssemblyInfo que, avec un petit évènement de post-build (ou plutôt, lors du publish de mes applis), j'irai stocker en contenu d'un fichier "version.txt" à la racine de chacune de mes appli.
 
Savez-vous comment mettre ça en place ?
Je ne sais pas comment je peux exécuter du code C#/VB.NET au moment de la publication de mon appli pour récupérer les infos de l'assembly et altérer un fichier texte :/
 
Merci d'avance pour votre aide
:hello:

mood
Publicité
Posté le 30-08-2019 à 17:40:06  profilanswer
 

n°2338562
TotalRecal​l
Posté le 31-08-2019 à 11:47:42  profilanswer
 

C'est pas aussi un petit peu leur job de backuper leur serveur quotidiennement avec des outils intelligents pour faire du backup différentiel ?  
Si un fichier a changé, on backupe, sinon on se repose sur le snapshot précédent.
Serveur backupé, binaire backupé aussi : simple.
 
Pour moi côté dév vous devez être capable de régénérer un build avec les sources d'un instant X et travailler sur une version précédente (branching pour patch, etc) mais pas vous occupez de savoir ce qu'il y a à restaurer sur les serveurs en cas de vautrage de l'infra, chacun son taf.
J'ai l'impression qu'il y a un glissement de la responsabilité là.
 
Mais sinon dans VS tu peux ajouter un Post Build Event qui fera tout ce que tu voudras, y compris appeler un EXE de ton cru qui générera dans le répertoire de publication les artefacts permettant de tracer les infos du build, genre dans ton fichier .txt avec ton numéro de version et l'instant où le build a été généré, etc.
Ca peut se faire aussi (un peu plus difficilement) après un Publish.  
 
Mais  
- Ca ne protège pas des rigolos qui vont mettre à jour des DLL directement en prod sans republier toute l'appli.
- Ca ne résoud pas le souci du backup des fichiers de conf qui sont parfois abominablement complexes.
- Cf début du post :o


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2338600
DiB91
Bwaaaaaaah
Posté le 01-09-2019 à 15:18:10  profilanswer
 

Merci pour ta réponse TotalRecall.
 
Entre temps, j'ai discuté un peu avec les gars, et on est tombé sur la même conclusion que toi.
Moi, je suis capable de gérer la version des binaires que je leur livre (et donc de leur publier une version N grâce à l'historisation du contrôle de code source), mais je peux pas leur assurer que le fichier "version.txt" sera garant de la nécessite de faire un backup ou pas...
 
Exemple concret : pour une modification d'urgence dans mes web.config, ou pour un hotfix dans un fichier HTML/XML/ASP (oui, on en a encore...), et suivant la criticité évidemment, je vais aller modifier à chaud et ramener le fichier chez nous dans le TFS... En aucun cas je vais prendre le risque de faire une livraison complète, de plusieurs dizaines de minutes, en pleine journée... et donc mettre à jour le fichier "version.txt" ...
 
A mon avis, tout comme toi, je pense que se baser sur les attributs / date modif des fichiers est bien plus parlant :jap:


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C#/.NET managed

  Versionning de projets .NET pour exploitation externe

 

Sujets relatifs
Requete pour traitement de plusieurs ProjetsSe connecter sur un VPN depuis VB.NET
[Perl] Remplacer plusieurs lignes par le résultat d'un appel externe[VB.Net] Comparaison insensible aux accents
Comment obtenir son IP public en .Net ?[ASP.NET] Bizarrerie avec les URL (ne correspondent pas !)
Problème utilisation librairie externe[ASP.NET] Alternative Crystal Reports pour hebergement ASP
Communication VBA vers VB.NET[VB.NET] Créer un formulaire a partir d'une classe
Plus de sujets relatifs à : Versionning de projets .NET pour exploitation externe


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR