.net et git - Comment éviter de modifier mon web.config mon appsetting à chaque pull fetch ?

exemple pull request

Vous ĂȘtes sur votre projet .net framework, ou votre projet .net core. Vous faites un fetch sur le repo commun. Et lĂ , de nouveau, de nouveau !, vous rĂ©cupĂ©rez un web.config / appsettings.json modifiĂ©, Ă  cause de la chaine de connection qui a encore Ă©tĂ© commit ….
Comment diable éviter ça à chaque fois ?

Git et le gitignore

Vous le savez, dans git, un des fichiers les plus importants, c’est le gitignore.
Du coup la solution, simple Ă  priori, c’est de mettre le web.config / appsettings en gitignore.

Ah ?! comment ça, ça ne fonctionne pas ?
Ben oui, vous souhaitez aussi pouvoir rĂ©cupĂ©rer votre travail chez vous (vous faites et du remote, et du travail dans l’entreprise).

Git et le fork

Dans la plupart des outils de gestionnaire de sources d’aujourd’hui (gitlab, github, bitbucket, …), vous avez un pouvoir immense, qui est Ă  portĂ©e de main : le fork.

Oui, le fork !

  1. Il est peu utilisĂ©, et pourtant c’est d’un pratique !
    Comment y arriver ?
    Vous prenez le repository commun sur votre outil prĂ©fĂ©rĂ© (gitlab, github, bitbucket, …)
  2. Vous allez chercher Ă  forker le projet, directement depuis l’interface de gestion sur votre navigateur
  3. Ca va créer un clone complet, donc un répo complet, à distance, qui vous servira de base de développement
  4. Et c’est ce projet que vous allez cloner !
  5. Et c’est ce projet oĂč vous pousserez (push) toutes vos modifications, y compris celle du web.config / appsettings !

 

Mise Ă  jour du repository commun

Une fois ce systĂšme mis en place, pour mettre Ă  jour le repository commun, comment faire ?

Il vous suffira de faire un Pull Request / Merge Request sur le repository commun.
C’est beaucoup plus propre, et en plus, cerise sur le gateau, ça permet aussi de favoriser une communication entre les devs !

exemple pull request

Seconde solution, si vous ne changez pas de pc

Sans aller vers le fork (mĂȘme si je vous invite Ă  le mettre en place), vous pouvez utiliser une technique qui est dĂ©jĂ  prĂ©sente dans Visual Studio / Msbuild.

Partie web.config / .net framework

Vous connaissez le principe depuis votre web.config, d’avoir des sous config, avec le configSource ?

  1. Vous allez donc en créer un que vous allez par exemple appeler : connectionString.dev.config, pour la partie ConnectionString.
  2. Ce fichier, vous le mettez dans le gitignore
  3. Vous allez créer un second fichier auxiliaire, appelé par exemple connectionString.recette.config
  4. Celui-lĂ , vous le committez avec Git
  5. Et vous allez utiliser la transformation des fichiers web.config pour remplacer, au moment du deploy, suivant la configuration choisie, le fichier connectionString.dev.config par connectionString.recette.config (ici, pour la recette)

Et hop, le tour est joué !

 

Partie appsettings.json / .net core

Pour la partie .net core, c’est encore plus simple, puisque les fichiers sont choisis suivant la valeur dans la variable d’environnement « ASPNETCORE_ENVIRONMENT ».

  1. Vous allez créer mettre votre configuration dans le fichier appSettings.json.
  2. Vous mettez ce fichier dans le gitignore
  3. Vous allez crĂ©er un fichier appSettings dĂ©diĂ© pour la recette (et idem pour la prod aprĂšs), qui sera utilisĂ© lorsqu’on sera en environnement de recette (ou de prod). Exemple de nom de fichier :  appsettings.Recette.json.
  4. Celui-lĂ , vous le committez dans Git.

Et hop, le tour est jouĂ© ! 🙂

Notre adresse

1 rue du guesclin
44000 Nantes

Notre téléphone

+33 2 79 65 52 87

Société

DevToBeCurious SARL
84860163900018 - Nantes B 848 601 639