J'essaie de travailler quel est le point du dossier des environnements.
À l'origine, j'avais l'idée que vous puissiez pointer le serveur Web sur les différents dans yii 1, vous résoudriez cela en suffisant en avoir plusieurs La question est donc quelle avantage cette nouvelle structure de l'environnement me donne-t-elle réellement sur l'ancienne? Dev et prod dans le dossier environnement , mais après avoir lu la lecture Un peu je me rends compte que ce n'est pas le cas.
index.php 's.:
index.php
index-local.php
5 Réponses :
Documentation Yii2 dans WIP, mais vous devriez lire ceci:
Vous devez utiliser la commande yii edit :
Cette nouvelle fonctionnalité Environnement est plus que d'utiliser un fichier de configuration différent. Vous pouvez utiliser une structure de dossiers différente, un script d'entrée différent ... etc
personnaly, je n'utiliserai pas cette fonctionnalité, je n'en ai pas besoin (je vais utiliser un script d'entrée différent comme avec Yii 1), mais je pense que ce n'est pas inutile. init pour basculer entre ces environnements.
Ce n'est pas ma question. Je sais que utiliser les environnements déjà
Je n'ai pas de réponse à ma question et je ne peux pas trouver une epxlanation raisonnable
Mis à jour, mais pas avec une "explication raisonnable" :)
Vous avez le même sentiment que moi par lequel j'ai envie de rester avec Yii1 façon de le faire. En fait, je pense que je peux voir un inconvénient à la configuration de l'envoi, il peut nier une envoi à la fois. Et si vous avez la même base de code qui passe à deux DBS différents, un travail et un vivent? Hmmm davantage, j'y pense plus, il semble que la partie Envotionnelle de Yii n'était pas très bien pensée si je suis honnête
Vous avez raison. Et je ne pense pas que Yii 2 apportera beaucoup de nouvelles fonctionnalités intéressantes (sauf les espaces de noms et les emballages de compositeur). Il restera toujours un très bon cadre MVC (mais Laravel est assez bon aussi).
Je pense que vous n'avez pas eu le but réel des environnements introduits dans Yii2.
Je vais essayer d'expliquer quel était le but principal d'ajouter des environnements à Yii du point de vue des développeurs sur un exemple et j'espère que vous apprécierez vraiment son utilité.
Supposons un instant que vous êtes une équipe de développeurs (par exemple 5 à 7 personnes) travaillant sur un projet mi-large mis en œuvre dans Yii. Pour travailler efficacement sur ce projet, votre équipe décide d'utiliser certains CVS ou SVN (E.G. Git) et conservez tous les fichiers du projet dans le référentiel dans Cloud pour toute l'équipe. C'est une norme de facto tout en travaillant sur des projets mi-a-grands dans les équipes et personne ne résistera que c'est le seul moyen confortable et facile.
OK, maintenant supposons utiliser Yii 1.x ou Yii2 avec l'approche de différents scripts d'entrée pour différencier les environnements locaux (développement) et de production pour se connecter à dB ou définir des configurations spécifiques à une autre environnement. Tout va bien et travaille. Mais supposons que vos membres de l'équipe ont mis en œuvre quelque chose de nouveau sur le projet et que vous consultez le référentiel de travailler sur la version mise à jour et que vous découvrez soudainement que votre fichier de configuration local (dans ce cas de script de saisie avec config) est écrasé avec le fichier d'autres membres de l'équipe qui a tiré le fichier Modifications apportées au référentiel (car chacun de vous utilise votre machine à dB locale avec un autre nom ou système d'exploitation, ou config, ou simplement parce que votre équipe utilise un serveur de développement local DB, mais vous êtes en vacances et ne pouvez rien utiliser à l'exception de votre local machine).
Généralement Yii2 Environnement ajoute plus de flexibilité pour utiliser différents environnements, chacun avec ses propres configurations spécifiques tout en utilisant également des configurations générales (communes) lorsque vous travaillez dans des projets au milieu de grands projets, pourquoi l'exemple de guide est donné sur l'application avancée. projet.
Vous pouvez sûrement surmonter tout ce qui précit avec certaines solutions ou .gitignore utilisé par défaut pour surmonter le problème indiqué dans Yii2 avec des environnements. Mais:
et
Globalement Yii2 est un excellent produit. Non seulement cela ajoute de nombreuses nouvelles fonctionnalités à un excellent cadre déjà, mais elle est également plus robuste et plus flexible que Yii 1.x (malgré le fait que Yii 1.x était déjà très robuste).
Quant au Laravel ou tout autre cadre PHP, cela dépend vraiment ... Tout le monde trouvera son propre favori.
Ce n'est déjà fait que parce que YII a ajouté le Gitignore, ce n'est pas un avantage héritable de l'utilisation de l'envoi Yii2. J'essaie de trouver son utilité dans un projet d'environ 200 tables et de 10 Devs, mais à ce que l'entrée locale et le fichier de configuration sont encore des règles du fait que cela n'obtienne pas l'espace de travail.
Je n'ai vraiment pas la facilité de votre approche. Si vous utilisez d'autres fichiers d'entrée pour Environnement Dev et d'obtenir la même chose qu'avec les environnements, vous devez également utiliser spécifique local .htaccess pour écraser le script d'entrée local par exemple. Et encore c'était un autre exemple. Je peux apporter beaucoup d'autres exemples que la nouvelle approche est meilleure et plus facile à utiliser. Votre argument est que vous ne pouvez pas utiliser deux environnements simultanément (sans init), mais si vous devez utiliser deux environnements à la fois, vous faites quelque chose de mal. Il y a toujours une distinction forte entre les environnements (dev, prod, test ...)
Non, j'ai un processus de mise en scène dans lequel le serveur Web de l'envoi local pointe vers l'index-local.php
@Sammaye un autre pour vous. Chaque grand projet implique. Et il y avait des migrations dans Yii 1.x et il existe des migrations dans Yii 2.x et elles sont largement utilisées dans de tels projets. Avec une approche de script d'entrée, qu'en est-il des migrations spécifiques à l'environnement? Il est courant d'avoir des migrations spécifiques à l'environnement.
Comment avoir un fichier d'un nom différent d'aide ici? Si vous devez avoir votre script d'entrée comme index.php qui ressemble à un mauvais codage
@Sammaye bon point que vous avez mentionné. Votre serveur Web local pointe vers Index-local.php et chaque device doit le savoir dans votre équipe et chaque device doit configurer chaque instance de serveur local (son ordinateur de travail, ordinateur domestique). Et vous pensez que c'est une bonne approche? Et qu'en est-il du nouvel dev dans votre équipe, ou si soudainement quelqu'un en équipe décide ou par erreur renommé Index-local.php dans le référentiel git commun (bien-être s'il est en repo).
Nous avons un git pour stocker chaque fichier de configuration de stockage, il est le seul moyen véritablement logique dans un grand projet, de cette façon lorsque vous allez configurer un ordinateur pour simplement copier le fichier Former le fichier WebBrowser ou le sortir et vous l'avez
@Sammaye Je n'ai pas compris votre commentaire sur le script d'entrée. Mais il doit y avoir un script d'entrée toujours et vous pouvez simplement manipuler toutes les autres choses en modifiant les configurations (locales, prod ...) et en modifiant une constante ou simplement en utilisant un script init pour cela.
Personne ne devrait jamais toucher l'index-local.php, si tel est le cas, alors ce qui les sote de renommer Index.php et de se mobiliser si elles sont comme ça?
Je soupçonne que nous pouvons discuter infiniment et que les commentaires ne sont pas un lieu approprié pour cela. Je vais donc conclure que c'est plus un problème de préférence. Notre équipe a trouvé le concept d'environnements dans Yii 2.x plus facile et flexible pour l'utilisation dans des projets mi-a-grands, tandis que pour des projets plus petits, il existe d'innombrables approches sans que tous les tracas avec des configures ou des scripts d'entrée.
Cela semble être une chose de préférence / configuration spécifique
J'ai trouvé des environnements très utiles pour me permettre de conserver une base de code commun pour plusieurs projets clients (basé sur l'application Yii Advanced) et à la configuration d'un environnement différent pour chaque client spécifique, en conservant leur code personnalisé privé et séparé.
Pour ce faire, je stocke le dossier d'environnements dans un repo git séparé du reste du code et retirez le dossier concerné sur un client / projet.
Cela me permet d'utiliser un code commun de base pour tous les projets et d'ajouter / remplacer tout fichier pour un client ou un projet spécifique tout en permettant toujours des paramètres de configuration Dev / Prod distincts. Si le client utilise également d'autres développeurs, ils sont également pris en charge. De cette manière, seul le code commun que j'ai choisi sera partagé parmi les clients et le code personnalisé sera conservé privé.
J'ai également déplacé le fichier compositeur.json dans le dossier ENVIRONNEMENTS afin que je puisse tirer dans différentes extensions par client / projet en gardant également ces personnes privées.
Cette commande init peut être un outil très puissant et vous n'avez pas à vous limiter au modèle fourni par les développeurs de base.
Si vous n'avez pas besoin d'environnements, ne les utilisez pas, mais je vous assure que certaines personnes le trouveront très utile.
J'ai aussi, même sur un seul client trouvé, j'ai trouvé cela plus utile, c'est-à-dire pas de configuration de serveur spécial pour clôturer d'autres fichiers d'index et des choses comme ça
Pour ceux qui sont fatigués de copier des fichiers autour, j'ai créé un script utile que vous pouvez exécuter en arrière-plan pour conserver les fichiers de la synchronisation de votre environnement de développement:
Sync-env-files.sh P>
nohup server/sync-env-files.sh >/dev/null 2>&1 &
J'aimerais mentionner en plus de @angelcoding, car cette question est toujours vue, que j'utilise les lots environnements maintenant et que vous voyez définitivement le point de celui-ci.
Les toutes premières choses que je fais dans n'importe quel projet open source est de créer un projet pour la base de code sur Github, puis un autre, privé, un sur Bitbucket pour la configuration, en d'autres termes, le dossier environnements .
Avoir ce dossier vous a rendu beaucoup plus facile pour moi de séparer ma configuration en un référentiel privé.
donc le dossier environnements a beaucoup d'utilisations et aide vraiment à séparer la configuration pour faciliter l'utilisation, même si cela ne semble pas l'être initialement.
Comment et quand êtes-vous en train de dire Yii de changer d'environnement? Je sais comment exécuter la commande et savoir ce que ça fait et ce que c'est pour. Si nous changeons de l'environnement localement, le repo git est hors de synchronisation. Nous devrons donc ajouter / commettre, puis appuyer sur le serveur. Cela semble être un obstacle non nécessaire d'enregistrements de validation. Mon hypothèse est donc qu'il serait préférable de le faire sur le serveur. Maintenant, je pourrais ssh dans et exécuter yii init. Je suppose que vous l'automatisez. Utilisez-vous GIT pour exécuter Yii Init après avoir poussé? Ou utilisez-vous un crochet dans votre hébergement? (IE OpenShift permet aux crochets dans votre configuration de exécuter des commandes) ..
@WADESHULER Le repo git serait hors de synchronisation quelle que soit la commande que vous exécutez, il créera toujours des fichiers que vous ne devez pas télécharger sur git. Tous les fichiers créés par la commande init ne doivent pas être en git. Nous l'avons dans le cadre d'une commande qui met à jour notre repo sur le côté serveur.