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 !
- 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, …) - Vous allez chercher à forker le projet, directement depuis l’interface de gestion sur votre navigateur
- Ca va créer un clone complet, donc un répo complet, à distance, qui vous servira de base de développement
- Et c’est ce projet que vous allez cloner !
- 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 !
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 ?
- Vous allez donc en créer un que vous allez par exemple appeler : connectionString.dev.config, pour la partie ConnectionString.
- Ce fichier, vous le mettez dans le gitignore
- Vous allez créer un second fichier auxiliaire, appelé par exemple connectionString.recette.config
- Celui-là, vous le committez avec Git
- 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 ».
- Vous allez créer mettre votre configuration dans le fichier appSettings.json.
- Vous mettez ce fichier dans le gitignore
- 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.
- Celui-là, vous le committez dans Git.
Et hop, le tour est joué ! 🙂