11
votes

Mercurial: Gardez 2 branches de synchronisation mais avec certaines différences persistantes?

Je suis un développeur Web travaillant seul avec Django, et j'essaie de me faire tourner la tête sur la meilleure façon de déployer des sites à l'aide de Mercurial. Ce que j'aimerais avoir, c'est que je puisse garder un référentiel que je puisse utiliser pour les travaux de production et de développement. Il y aura toujours des différences entre la production / le développement (par exemple, ils pourraient utiliser différentes bases de données, le développement aura toujours du débogage) mais d'une manière générale, elles seront synchronisées. J'aimerais également pouvoir apporter des modifications directement sur le serveur de production (rangée HTML ou CSS, de bugfixes simples, etc.).

Le flux de travail que j'ai l'intention d'utiliser pour ce faire est comme suit:

Créez 2 branches, produit et dev (tous les paramètres initialement définis sur les paramètres de production)
changer les paramètres.py et quelques autres choses dans la branche de développement. Alors maintenant, j'ai 2 têtes, et à partir du référentiel aura toujours 2 têtes.
(sur Dev Dev Machine) apporte des modifications à Dev, puis utilisez «GRANDSPANT HG» pour copier les modifications correspondantes à la production.
Poussez sur le référentiel principal
(sur serveur de production) Tirez de Master Repo, mise à jour de PROD HEAU
Remarque: vous pouvez également apporter des modifications directement à pousser tant que vous transposez les modifications dans Dev.
Ce flux de travail a l'inconvénient que chaque fois que vous effectuez une modification, vous devez non seulement l'engager à la branche qui vous entraîne, vous devez également le transplanter à l'autre branche. Y a-t-il une façon plus judicieuse de faire ce que je veux ici, peut-être utiliser des patchs? Ou à défaut, existe-t-il un moyen d'automatiser le processus de validation de transplanter automatiquement la modification de l'autre branche et serait-ce une bonne idée?

django mercurial

1 commentaires

Je vais peser avec une réponse ci-dessous, bien que l'excellente suggestion de Steve L. ait déjà été sélectionnée, mais je tiens à souligner que l'indépendante de la façon dont vous le faites enfin, la transplantation est un particulièrement mauvaise façon de le faire. La greffe effectue une exportation, puis une importation, qui donne à votre contact un nouvel identifiant de hash / noeud. Si chaque changements change de noms entre le développement et la production, vous demandez des problèmes de suivi de ce qui a été corrigé où et où un problème a été introduit. Rendre HG entrant et HG sortant inutilisable entre Dev et Prod demande des problèmes.



                                    
                    5 Réponses :
                    
                                            
                            
                                
                                    1
 votes
                                
                            
                            
                                
                                     J'essaie peut-être quelque chose comme ceci: (Je pensais juste à cette question, dans mon cas c'est une base de données SQLite) 


 Ajouter  Params.py  à .hgignore, pour le garder hors du référentiel. 
 Prenez vos fichiers  Params.py (code> des deux branches distinctes et déplacez-les en deux fichiers distincts,  paramètres-prod.py  et  paramètres-dev.py  
 Créez un script de déploiement qui copie le fichier Paramètres approprié-x sur Paramètres.py, afin que vous puissiez déployer de toute façon. 


 Si vous avez quelques fichiers supplémentaires, faites la même chose pour eux. Si vous avez beaucoup de fichiers, mais ils sont tous dans le même répertoire par elles-mêmes, vous pouvez simplement créer une paire de répertoires:  production  et  développement , puis en copie ou symbolique le approprié dans un répertoire  . 

 Si vous avez fait quelque chose comme ça, vous pourriez vous dispenser avec la nécessité de ramifier votre référentiel.                                 


                                                                    
                                    
                                    
                                        1 commentaires
                                        
                                                                                            
                                                    J'aime cette approche en raison de son manque de succursales, j'utilise en fait un autre déjà similaire. Au lieu de faire 2 fichiers de paramètres, je crée un répertoire des paramètres et mettez un fichier  __ init __. Py  fichier ajoutez mes fichiers de paramètres de connexion, PROD.PY et DEV.PY (idée levée de ce blog: < Un href = "http://blog.haydon.id.au/2009/07/django-development-workflow.html" rel = "nfollow noreferrer"> blog.haydon.id.au/2009/07/django-development -workflow.h tml ). Ensuite, il suffit de symboliser le bon script WSGI dans. Mais malheureusement, je dois modifier également certains modèles, la production utilise des versions minissiques de JavaScript et de Dev Utilisations non ciindifiées, et je ne pense pas que je puisse le faire sans que je puisse le faire sans un symbole sympathique.                                                

                                                
                                                                                    

                                    

                                                            

                        

                        
                                            
                            
                                
                                    5
 votes
                                
                            
                            
                                
                                     J'utiliserais probablement des files d'attente mercuriales pour quelque chose comme ça. Gardez le référentiel principal en tant que version de développement et disposez d'un correctif  pour la production  qui apporte les modifications nécessaires à la production.                                 

                                                                    
                                    
                                    
                                        1 commentaires
                                        
                                                                                            
                                                    Mercurial files d'attente extension  mercurial.selenic.com/wiki/mqextension  Tutoriel d'extension des files d'attente Mercurial  mercurial.selenic.com/wiki/mqTutorial                                                 
                                                
                                                                                    
                                    
                                                            
                        
                        
                                            
                            
                                
                                    2
 votes
                                
                            
                            
                                
                                     Voici deux solutions possibles, on Mercurial et on ne Mercurial: 


 Utilisez le nom d'hôte pour basculer entre prod et devel. Nous avons un seul chèque en haut de nos fichier de paramètres qui ressemble à la variable d'environnement SERVER_NAME. Si c'est www.production.com c'est la prod DB et sinon il prend une durée déterminée ou par défaut dev / test / stade DB. 
 Mercurial, ont juste un clone qui dev et de un clone qui est prod, faire tous les changements dans dev, et à tirer le temps de déploiement de dev pour prod. Une fois que vous aurez en tirant 2 têtes en prod divergentes d'un seul ancêtre commun (la dernière) Déployez. Une tête aura un seul contenant changeset uniquement les différences entre les déploiements de dev et prod, et l'autre aura tous les nouveaux travaux. les fusionner dans le clone de prod, en sélectionnant les changements de prod sur le conflit bien sûr, et vous avez une configuration déployable, et sont prêts à faire plus de travail sur le « dev ». Pas besoin de branche, transplantation, ou les files d'attente d'utilisation. Tant que vous ne tirez jamais ce changeset avec les paramètres prod dans « dev » il aura toujours besoin d'une fusion après avoir tiré de dev, et si elle est juste quelques lignes il n'y a pas grand-chose à faire. 
                                

                                                                    
                                    
                                    
                                        0 commentaires
                                        
                                                                                    
                                    
                                                            
                        
                        
                                            
                            
                                
                                    1
 votes
                                
                            
                            
                                
                                     Je fais en fait cela en utilisant des branches nommées et une fusion droite au lieu de transplanter (qui est plus fiable, imo). Cela fonctionne généralement, bien que parfois (lorsque vous avez édité les différents fichiers de l'autre branche), vous devez faire attention à ne pas supprimer les différences lorsque vous fusionnez. 

 Cela fonctionne donc bien si vous ne modifiez pas beaucoup les différents fichiers.                                 

                                                                    
                                    
                                    
                                        0 commentaires
                                        
                                                                                    
                                    
                                                            
                        
                        
                                            
                            
                                
                                    2
 votes
                                
                            
                            
                                
                                     J'ai résolu ce avec les paramètres locaux. 

  Append à settings.py:
 
<script type="text/javascript" src="blabla{{JS_EXTENSION}}"></script>
   touche local_settings.py  code>  p>  li>
 Ajouter  ^ local_settings.py $  code> à votre  .hgignore  code>  li>
 Ol>  Chaque Déployez je possède ses propres paramètres locaux (généralement différentes choses DB et différentes adresses e-mail d'origine)  p> 
 PS:. Seulement lire les « versions minified de la partie javascript » plus tard. Pour cela, je suggère un crochet post-mise à jour et un paramètre de configuration (comme JS_EXTENSION)  p> 
 Exemple (à partir du haut de ma tête non testé, adapter au besoin!).  P> 

 Mettre JS_EXTENSION = » .raw.js' dans votre  settings.py  code>;  li>
 Mettre JS_EXTENSION = » .mini.js' dans votre  local_settings.py fichier  code> sur le serveur de production;  li>
 Modifier l'inclusion JS à partir de:
 <script type="text/javascript" src="blabla.js"></script>

                                

                                                                    
                                    
                                    
                                        1 commentaires
                                        
                                                                                            
                                                    Cette méthode est jolie bien rangée. J'aime la partie js_extension, fait exactement ce que je voulais et donne un sens immédiatement.