S'il s'agit d'un doublon, veuillez l'indiquer comme tel. De plus, je ne sais pas exactement si ce serait une question basée sur l'opinion. Ma recherche sur Google n'a rien rapporté de pertinent à ma situation difficile, et je ne sais pas non plus ce que je devrais faire sur Google. ( 1 , 2 )
Ma question est de savoir comment empêcher qu'un fichier de production .htaccess suivi dans git n'interfère avec le serveur Web de mon environnement de développement.
Une brève description de ma configuration de déploiement git:
Machine locale (dev) -> Bitbucket -> Production
La production est sur un hôte partagé, donc je ne peux pas passer directement en production depuis le développement, je dois utiliser Bitbucket comme intermédiaire.
Mon environnement de développement:
J'utilise Vagrant localement comme environnement de développement, qui utilise Apache comme serveur Web. Le script de configuration de vagrantbox applique les modifications dans le fichier httpd.conf pour configurer VirtualHost , DocumentRoot et DirectoryIndex .
Cela a bien fonctionné pour moi dans le passé.
En production, Apache est également utilisé. À l'origine, je n'avais pas suivi .htaccess dans git, mais il y a eu un changement récemment (une redirection HTTP vers HTTPS) qui m'a décidé à commencer à le suivre. Le problème que j'ai maintenant est que le fichier de production .htaccess est extrait dans mon répertoire de développement et affecte mon serveur Web de développement.
Voici quelques idées que j'avais:
.htaccess en production qui ne sera pas ajouté à Bitbucket ou au développement, mais cela me semble alambiqué. .htaccess mais ... je prévois que cela deviendra compliqué pour moi car je jonglerai avec les branches sur prod / dev et il y a de fortes chances que je visse quelque chose en cours. .htaccess , mais cela semble être une recette pour un désastre plus tard. Y a-t-il une autre façon de faire cela? Ou devrais-je utiliser l'une des idées auxquelles j'ai pensé?
3 Réponses :
L'approche de branche pourrait être une bonne idée, peut-être une branche de développement sans les fichiers .htaccess et une branche de production comme master avec le tracking. Ainsi, lorsque vous avez quelque chose de prêt pour la production, vous effectuez une fusion à maîtriser.
J'ai remarqué la question du PO deux minutes trop tard - vous avez répondu en premier :). Une "branche" (par exemple "dev") est probablement idéale pour des cas comme celui-ci. Pour répondre à l'inquiétude du PO - il n'est pas nécessaire que les choses se «salissent». Dans un environnement CI / CD, l'utilisation de branches serait probablement plus propre .
Je n'avais pas pensé à ça. Le projet pour lequel j'utilise ceci est assez mineur, donc je me suis engagé directement dans master et je ne branche que pour les fonctionnalités que je suis en train de terminer mais qui ne sont pas prêtes pour la production. Je suppose qu'alors je créerais une branche de développement localement et supprimerais la branche master . Bitbucket aurait à la fois développement et maître , et je pourrais fusionner la branche développement dans master sur Bitbucket, puis tirer maître de la production. Cela vous semble-t-il correct?
Exactement raison. Vous n'aurez peut-être même pas besoin de fusionner. Bien sûr, une autre possibilité est d'avoir deux fichiers: un pour prod, l'autre pour dev. Vous pouvez enregistrer les deux, mais les mettre dans des répertoires séparés (/prod/.htaccess, /dev/.htaccess) ou leur donner des noms séparés (.htaccess.prod, .htaccess.dev).
L'autre réponse est probablement celle que vous recherchez, cependant, il peut y avoir quelques alternatives sans changer le contrôle de version ...
Si votre environnement de développement local n'utilise pas .htaccess du tout, alors vous pouvez désactiver cela dans la configuration de votre serveur, alors peu importe si le fichier prod .htaccess est présent ou non:
<IfDefine DEV>
# Development server directives...
</IfDefine>
<IfDefine !DEV>
# Production server directives...
</IfDefine>
Si vous avez besoin de .htaccess à la fois dans prod et dev mais avec (certaines) directives différentes, vous pouvez inclure des conditions dans votre fichier .htaccess . Vous pouvez le faire de différentes manières, l'une d'entre elles est de Définir une variable dans la configuration du serveur de votre serveur de développement et de vérifier cela dans .htaccess .
Par exemple, dans la configuration de votre serveur:
Define DEV
In .htaccess:
<Directory /path/to/public_html>
# Disable .htaccess files...
AllowOverride none
</Directory>
Notez le préfixe ! (not) sur le deuxième bloc de règles.
J'aime mieux cette approche que de garder deux branches, mais avoir deux branches dans git est probablement la bonne façon de résoudre le problème. J'ai du mal à gérer les branches et les hôtes distants dans git et je peux me voir écraser accidentellement quelque chose dans le développement qui nécessiterait beaucoup de travail et de jonglage de fichiers pour que je le répare.
Oui, je suis d'accord, bien que «correct» peut-être subjectif - YMMV. J'utilise souvent un seul conditionnel dans .htaccess pour différencier les serveurs live / développement car il peut juste y avoir une petite différence de chemin entre les deux et il est souvent plus facile de maintenir cela ensemble dans le même fichier.
J'ai rencontré exactement le même problème ... ce que je fais actuellement, c'est que je garde mon répertoire de développement de travail sous / var / www / site [dev] / mais j'ai gitignoré les fichiers .htaccess avec tout ce qui n'est que pour le développement. Ensuite, je garde un deuxième répertoire juste à côté dans / var / www / site [prod] / avec toutes les variantes que je veux sur le serveur de production. Je m'engage et pousse depuis [dev], je reviens vers [prod] et déploie à partir de là. Je veux dire, cela fonctionne - mais j'ai l'impression qu'il devrait y avoir une norme de l'industrie pour des choses comme celle-ci, c'est pourquoi je suis ici. Mais peu importe, je suppose que si ça marche, ça marche. shrugs