Comment créer un site Web approprié?

Question

Le développement Web n'est plus ce qu'il était. Il consistait à hacker ensemble quelques scripts PHP (je n'ai rien contre PHP, en fait c'est actuellement mon principal langage de programmation), en les téléchargeant via FTP vers un hébergeur et c'est tout. Aujourd'hui, les choses sont plus compliquées. Comme je peux le voir en regardant un certain nombre de sites Web professionnels et modernes (SO étant le principal, je considère que SO est un excellent exemple de bonne pratique dans le développement web, même si elle est faite avec ASP.NET et hébergé sur Windows), développant un site Web est beaucoup plus que cela:

1. le code de site est en fait dans un dépôt (ce petit de révision svn en bas de page fait mes sentiments ringard picotent);
2. Les fichiers statiques (CSS, JavaScript, images) sont stockés sur un domaine distinct;

Ok, ce sont mes observations. Maintenant pour mes questions:

1. Que faites-vous avec les fichiers JavaScript et CSS? Ne les gardez-vous pas sous contrôle de version? Cela semblerait stupide. Créez-vous un référentiel séparé pour eux?
2. Comment configurez-vous le référentiel? En créez-vous un à la racine du serveur Web? Ou créez-vous une sorte de déclencheur post-commit qui copie les derniers fichiers vers leurs destinations appropriées? Que se passe-t-il si plusieurs machines exécutent le site Web et que vous souhaitez y apporter des modifications?
3. Chaque projet de ce type doit avoir des fichiers de configuration. Ceux-ci diffèrent du référentiel local au distant. Par exemple, sur ma machine de développement, je n'ai pas de mot de passe root MySQL, alors que sur le serveur de production j'ai certainement un mot de passe. Ce mot de passe serait stocké dans un fichier de configuration, entre autres, ce qui serait complètement différent sur ma machine et sur le serveur. Peut-être sont-ils également différents entre les machines de production (comme je l'ai déjà dit, peut-être que le site fonctionne sur plusieurs machines pour l'équilibrage de charge). Comment puis-je gérer cela?

Je cherche à lancer un nouveau projet Web en utilisant:

• Python + SQLAlchemy + Werkzeug + Jinja2
• Apache httpd + modwsgi
• MySQL
• Mercurial

Ce que je voudrais, c'est un conseil de bonne pratique sur l'utilisation des outils susmentionnés et répondre s à mes questions ci-dessus.

Answer 1

Vous avez raison, les choses peuvent se compliquer lorsque vous essayez de déployer un site Web évolutif. Voici ce que j'ai trouvé être quelques bonnes directives (disclaimer: Je suis ingénieur rails):

1. La plupart des décisions relatives à la structure de fichier pour votre référentiel de code sont en grande partie basées sur la convention du langage, cadre et plate-forme que vous choisissez de mettre en œuvre. La plupart des questions que vous avez posées (JS, CSS, assets, production vs développement) sont traitées avec Rails. Cependant, cela peut différer de PHP à Python à n'importe quelle autre langue que vous voulez utiliser. J'ai trouvé que vous devriez faire des recherches sur la langue que vous choisissez d'utiliser, et essayer de trouver un moyen de s'adapter à la convention de cette communauté. Cela vous aidera lorsque vous essayez de trouver de l'aide sur un obstacle plus tard. Votre code sera organisé comme leur code, et vous serez en mesure d'obtenir des réponses plus facilement.

2. Je voudrais la version contrôler tout ce qui n'est pas très important en taille. Le seul problème que j'ai trouvé avec VC est quand votre repo devient grand. A part ça je n'ai jamais regretté de garder une version du code précédent.

3. Pour le déploiement sur plusieurs serveurs, de nombreux scripts peuvent vous aider à accomplir ce que vous devez faire. Pour Ruby/Rails, l'outil le plus utilisé est Capistrano. Il existe également des ressources comparables pour d'autres langues. Fondamentalement, vous avez juste besoin de configurer la configuration de votre serveur, puis d'écrire ou de rechercher l'open source pour un ensemble de scripts qui peuvent déployer/restaurer/manipuler votre code vers les serveurs que vous avez décrits dans votre fichier de configuration.

4. Développement vs Production est une distinction importante à faire. Alors que vous pouvez opérer sans cette distinction, il devient lourd quand vous devez patcher du code partout dans votre référentiel. Si j'étais vous, j'écrirais du code qui est exécuté au début de chaque requête qui détermine l'environnement dans lequel vous exécutez. Ensuite, vous avez cette connaissance à votre disposition lorsque vous traitez cette requête.Ces informations peuvent être utilisées lorsque vous spécifiez la configuration que vous souhaitez utiliser lorsque vous vous connectez à votre base de données, tout en affichant les informations de débogage dans le navigateur uniquement lors du développement. C'est pratique. Etre RESTful dicte souvent une grande partie de votre conception en ce qui concerne la façon dont les pages de votre site sont découvertes. Essayer de garder votre code dans le cadre reposant vous aide à vous souvenir où se trouve votre code, à garder votre routage prévisible, à éviter que votre code ne soit trop couplé et à suivre une convention de plus en plus acceptée. Il y a évidemment d'autres conventions qui peuvent atteindre ces mêmes objectifs, mais j'ai eu une grande expérience en utilisant REST et cela a considérablement amélioré mon code.

Tout cela étant dit. J'ai trouvé que même si vous pouvez avoir de bonnes intentions pour créer une base de code vierge qui peut évoluer à l'infini et qui est agréable et propre, il en résulte rarement. Si j'étais vous, je ferais une petite recherche sur ce que vous ressentez le plus à l'aise et sur ce qui vous aidera à vous rendre la vie plus facile.

Espérons que cela aide!

Answer 2

Même si j'ai peu d'expérience avec les outils que vous avez mentionnés, à l'exception de MySQL, je peux vous donner quelques réponses assez standard pour les questions que vous avez postées.

1) Dépend des détails, mais le plus souvent vous les conservez dans le même référentiel mais dans un dossier séparé. 2) Tout simplement parce que quelque chose est engagé dans le dépôt ne signifie pas qu'il est prêt à être mis en ligne - il s'agit souvent d'une construction intermédiaire qui pourrait être criblée de bogues. Une publication est effectuée manuellement, avec une exportation à partir du référentiel. Configurer le serveur web dans le même dossier que svn checkout est un énorme nono car le dossier .svn contient pas mal d'informations sensibles, comme la manière de pousser les changements sur le serveur svn.

3) Vous utilisez une sorte de solution NAS ou SAN, ou simplement un partage réseau sur l'un des serveurs, et lisez toutes vos données à partir de là. Ainsi, lorsque vous placez des informations à un endroit, elles sont accessibles à tous les serveurs. Si votre réseau est lent, vous configurez des scripts qui poussent automatiquement les fichiers vers tous les serveurs à partir d'un emplacement unique. Si vous utilisez un environnement multiserveur dans ASP.NET, n'oubliez pas de mettre à jour la clé machine dans les fichiers de configuration ou vos caches cryptés partagés, comme viewstate, ne fonctionneront pas sur les serveurs. Avoir un magasin de session dans une base de données est également une bonne idée. 4) J'ai une étape de post-construction qui ne déclenche que la publication qui remplace mes chaînes de connexion de base de données par des chaînes de production, et qui modifie également ma valeur de configuration de l'application Production de faux à vrai dans le fichier web.config/app.config publié des dossiers. Je ne vois aucun cas où vous voudriez des fichiers de configuration différents pour différents serveurs desservant le même contenu.

Si quelque chose n'est pas clair, il suffit de commenter et je vais essayer de clarifier.

Bonne chance! // Eric Johansson

Answer 3

Je pense que vous mélangez 2 aspects différents, le contrôle de la source et le déploiement. Le simple fait que vous ayez tous vos fichiers dans un seul référentiel ne signifie pas qu'ils doivent être déployés de cette façon. On peut également se demander si vous devriez déployer directement en utilisant le contrôle de source ou à la place en utilisant un script build/deploy qui pourrait gérer n'importe quel nombre de configurations. De plus, l'hébergement de fichiers statiques sur un domaine séparé ne vaut vraiment la peine que sur des sites Web à fort trafic. Êtes-vous sûr de ne pas optimiser prématurément?