github - En utilisant git pour gérer le code, la branche de développement et la branche en ligne ont des fichiers différents, comment les gérer

Question

Lorsque vous utilisez git pour la gestion du code, il existe une branche de développement dev et une branche en ligne pro.

Pendant le développement, chacun extraira sa propre branche de la branche dev, la développera et la fusionnera dans la branche dev une fois terminée.
Lorsque l'environnement en ligne est mis à jour, le dernier code sera extrait de la branche pro, puis le service sera redémarré.

Il y a un problème ici. La branche dev et la branche pro ont souvent plusieurs fichiers différents, comme des fichiers de configuration, des paramètres, etc. Quelle devrait être l’approche appropriée dans cette situation ?

Si le fichier de paramètres n'est pas inclus dans git, si le fichier de configuration doit être mis à jour, le code doit être modifié manuellement dans l'environnement en ligne.

Comment as-tu fait ? Combiner git pour réaliser un déploiement et une restauration automatisés ?

Merci

Answer 1

Différences d'environnement :

La différence entre l'environnement de production et l'environnement de non-production (comme l'environnement de développement, l'environnement de test, etc.), en plus de la configuration, il peut y avoir certaines ressources dépendantes qui sont également différentes.

Fichier de configuration :

La méthode courante que j'utilise ici est d'écrire toutes les configurations de l'environnement de production et d'autres environnements dans ce fichier de configuration (ou plusieurs fichiers config/dev.json, config/pro.json...), et puis il y a une configuration Le processeur se chargera de lire ce qu'est l'environnement local (ceux-ci sont inclus dans la portée de git, et peuvent être le module d'initialisation), puis de lire la configuration de l'environnement correspondant dans le fichier de configuration s'il y en a seulement. un fichier de configuration, il ressemble à ce qui suit :

{
    'pro':{
        'ver':'0.1.0',
        'configA':'value'
    },
    'dev':{
        'ver':'0.1.12',
        'configA':'value'
    },
    'test'{
        'ver','0.1.32',
        'configA':'value'
    }
    ...
}

Label Environnemental

Comment le processeur de configuration sait-il quel est l'environnement actuel ? Il doit y avoir un 环境标识 ici. Un plus direct et plus étendu peut être une adresse IP. Par exemple, l'environnement de production est déployé sur une IP fixe (. adapté à une seule application à serveur unique), la configuration de l'environnement de production du fichier de configuration est écrite sous cette IP. Une fois que le processeur de configuration a obtenu l'IP de l'environnement d'exécution actuel, il lit la configuration du module IP spécifié dans le fichier de configuration. 🎜> Une autre façon consiste à utiliser un
, par exemple, il existe un fichier texte /data/tag dans tous les environnements où l'application est en cours d'exécution (il peut également être dans le répertoire du projet, mais inclus avec .gitignore). Le fichier n'est pas dans le cadre de git. Il ne contient qu'une seule ligne, écrite 标识文件 ou pro, afin que le processeur de configuration sache quelle partie du fichier de configuration obtenir en lisant ce fichier dev. La méthode la plus courante consiste à utiliser des variables d'environnement, telles que
, puis à lire d'abord cette variable. Relisez la configuration correspondante de votre environnement.export APP_ENV=production

Serveur de configuration

Dans la période ultérieure, la plupart des applications sont déployées de manière distribuée, c'est-à-dire que la même application peut être déployée sur plus de 20 serveurs ou plus. À ce stade, il doit y avoir un

serveur de configuration. pour le gérer et le distribuer spécifiquement. Mettez à jour la configuration de l'application de chaque serveur. Sur ce serveur de configuration, vous pouvez configurer indépendamment quels serveurs utilisent quelle configuration (généralement configuré avec l'adresse IP du demandeur). Chaque application ira sur le serveur de configuration. demander sa propre configuration au démarrage.
De cette façon, l'application peut être complètement apatride,
aucun fichier de configuration n'est nécessaire et la configuration peut être contrôlée avec une granularité fine (par exemple, Je souhaite augmenter le flux de requêtes d'un certain serveur), en plus de réaliser une version en niveaux de gris (déploiement de nouveau code sur certains serveurs), je pense que c'est peut-être la méthode adoptée par la plupart des sociétés Internet actuellement .

Answer 2

Définissez le fichier ignoré et stockez différents paramètres de configuration dans le fichier ignoré.