Wie erstelle ich eine richtige Website?

Question

Web-Entwicklung ist nicht mehr das, was es einmal war. Früher bestand es darin, ein paar PHP-Skripte zu hacken (ich habe nichts gegen PHP, eigentlich ist es momentan meine Hauptprogrammiersprache), sie per FTP auf einen Webhost zu laden und das war es. Heute sind die Dinge komplizierter. Wie ich an einer Reihe von professionellen und modernen Websites (SO ist die wichtigste, ich denke, dass SO ein großartiges Beispiel für gute Praxis in Web-Entwicklung ist, selbst wenn es mit ASP.NET gemacht und auf Windows gehostet wird), zu entwickeln, zu sehen eine Website ist viel mehr als das:

1. der Code Website ist eigentlich in einem Repository (die kleine sVN Revision in der Fußzeile macht meine nerdy Gefühle kribbeln);
2. Statische Dateien (CSS, JavaScript, Bilder) werden in einer separaten Domäne gespeichert;

Ok, das waren meine Beobachtungen. Jetzt für meine Fragen:

1. Was machen Sie mit JavaScript und CSS-Dateien? Behalten Sie sie nicht unter Versionskontrolle? Das würde dumm erscheinen. Erstellen Sie ein separates Repository für sie?
2. Wie richten Sie das Repository ein? Erstellst du einfach einen im Stamm des Webservers? Oder erstellen Sie eine Art Post-Commit-Trigger, der die neuesten Dateien an die entsprechenden Ziele kopiert?
3. Was passiert, wenn mehrere Computer die Website ausführen und einige Änderungen an ihnen vornehmen möchten?
4. Jedes solche Projekt muss Konfigurationsdateien haben. Diese unterscheiden sich vom lokalen Repository zum Remote-Repository. Auf meinem Entwicklungscomputer habe ich zum Beispiel kein MySQL-Root-Passwort, während ich auf dem Produktionsserver sicher ein Passwort habe. Dieses Passwort würde unter anderem in einer Konfigurationsdatei gespeichert werden, was auf meinem Rechner und auf dem Server völlig anders wäre. Vielleicht unterscheiden sie sich auch zwischen Produktionsmaschinen (wie ich bereits sagte, vielleicht läuft die Website auf mehreren Maschinen zum Lastenausgleich). Wie gehe ich damit um?

Ich suche ein neues Web-Projekt zu beginnen:

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

Was ich möchte, ist ein Best-Practice-Rat zur Verwendung der oben genannten Tools und Antworten s zu meinen Fragen oben.

Answer 1

Sie haben Recht, bei der Bereitstellung einer skalierbaren Website kann es kompliziert werden. Hier sind das, was ich gefunden habe, ein paar gute Richtlinien zu sein (Disclaimer: Ich habe einen Schienen-Ingenieur bin):

1. Die meisten Entscheidungen Dateistruktur für die Code-Repository in Bezug auf sind auf dem Kongress der weitgehend auf Basis Sprache, Framework und Plattform, die Sie implementieren möchten. Viele der von Ihnen aufgeworfenen Fragen (JS, CSS, Assets, Produktion versus Entwicklung) werden mit Rails bearbeitet. Dies kann jedoch von PHP zu Python zu der anderen Sprache, die Sie verwenden möchten, abweichen. Ich habe herausgefunden, dass Sie etwas über die Sprache, die Sie verwenden möchten, recherchieren und versuchen sollten, einen Weg zu finden, der Konvention dieser Gemeinschaft zu entsprechen. Dies wird Ihnen helfen, wenn Sie später Hilfe zu einem Hindernis suchen. Ihr Code wird wie sein Code organisiert, und Sie werden leichter Antworten erhalten.

2. Ich würde Version alles kontrollieren, die nicht sehr groß ist. Das einzige Problem, das ich mit VC gefunden habe, ist, wenn Ihr Repo groß wird. Abgesehen davon habe ich es nie bereut, eine Version des vorherigen Codes zu behalten.

3. Für die Bereitstellung auf mehreren Servern stehen zahlreiche Skripts zur Verfügung, mit denen Sie Ihre Aufgaben ausführen können. Für Ruby/Rails ist Capistrano das am häufigsten verwendete Werkzeug. Für andere Sprachen gibt es vergleichbare Ressourcen. Im Grunde müssen Sie lediglich konfigurieren, wie Ihr Server-Setup aussieht, und dann Open Source für eine Reihe von Skripten schreiben oder suchen, die Ihre Codebasis auf den Servern bereitstellen, die Sie in Ihrer Konfigurationsdatei beschrieben haben.

4. Entwicklung vs Produktion ist eine wichtige Unterscheidung zu machen. Während Sie ohne diese Unterscheidung arbeiten können, wird es schnell umständlich, wenn Sie Code in Ihrem gesamten Repository patchen müssen. Wenn ich Sie wäre, würde ich Code schreiben, der zu Beginn jeder Anfrage ausgeführt wird, die bestimmt, in welcher Umgebung Sie arbeiten. Dann steht Ihnen dieses Wissen zur Verfügung, wenn Sie diese Anfrage bearbeiten.Diese Informationen können verwendet werden, wenn Sie angeben, welche Konfiguration beim Herstellen einer Verbindung zu Ihrer Datenbank verwendet werden soll, und die Debuginformationen nur während der Entwicklung im Browser anzeigen. Es ist praktisch.

5. Oft RESTful diktiert oft viel von Ihrem Design in Bezug auf wie die Seiten Ihrer Website entdeckt werden. Wenn Sie versuchen, Ihren Code in einem ruhigen Rahmen zu halten, können Sie sich daran erinnern, wo sich Ihr Code befindet, Ihr Routing vorhersehbar halten, Ihren Code nicht zu stark miteinander verbinden und einer Konvention folgen, die immer mehr akzeptiert wird. Es gibt offensichtlich andere Konventionen, die dieselben Ziele erreichen können, aber ich hatte eine großartige Erfahrung mit REST und es hat meinen Code wesentlich verbessert.

All das wird gesagt. Ich habe festgestellt, dass es zwar gute Absichten gibt, eine makellose Codebase zu erstellen, die unbegrenzt skalierbar ist und nett und sauber ist, aber das kommt selten so vor. Wenn ich Sie wäre, würde ich eine kleine Menge Forschung darüber machen, mit was Sie sich am wohlsten fühlen und was Ihnen helfen wird, Ihr Leben einfacher zu machen, und damit fortfahren.

Hoffentlich hilft das!

Answer 2

Während ich wenig Erfahrung mit den Tools, die Sie erwähnt haben, mit Ausnahme von MySQL, kann ich Ihnen ein paar ziemlich Standard-Antworten für die Fragen, die Sie veröffentlicht haben, geben.

1) Hängt von den Details ab, aber meistens werden sie im selben Repository gespeichert, aber in einem separaten Ordner.

2) Nur weil etwas mit dem Repository verbunden ist, bedeutet das nicht, dass es bereit ist, um live zu gehen - es ist oft ein intermediärer Build, der mit Fehlern durchsetzt sein könnte. Eine Veröffentlichung erfolgt manuell mit einem Export aus dem Repository. Das Einrichten des Webservers im selben Ordner wie beim svn checkout ist ein großes Nono, da der .svn-Ordner ziemlich viele sensible Informationen enthält, wie zum Beispiel Änderungen an den svn-Server zu übertragen.

3) Sie verwenden eine Art von NAS- oder SAN-Lösung oder einfach eine Netzwerkfreigabe auf einem der Server und lesen alle Ihre Daten von dort. Auf diese Weise ist es für alle Server zugänglich, wenn Sie Informationen an einen Ort übertragen. Wenn Ihr Netzwerk langsam ist, richten Sie Skripts ein, die die Dateien automatisch von einem einzigen Standort an alle Server senden. Wenn Sie eine Multi-Server-Umgebung in ASP.NET verwenden, vergessen Sie nicht, den Computerschlüssel in den Konfigurationsdateien zu aktualisieren, da Ihre gemeinsam genutzten verschlüsselten Caches (z. B. viewstate) nicht über mehrere Server hinweg funktionieren. Es ist auch eine gute Idee, einen Sitzungsspeicher in einer Datenbank zu haben.

4) Ich habe einen Post-Build-Schritt, der nur bei Veröffentlichung auslöst, der meine Datenbank-Connectionstrings durch Produktion ersetzt und auch den Production-App-Konfigurationswert von false in true in der veröffentlichten web.config/app.config ändert Dateien. Ich sehe keinen Fall, in dem Sie unterschiedliche Konfigurationsdateien für verschiedene Server wünschen, die den gleichen Inhalt bereitstellen.

Wenn etwas unklar ist, nur kommentieren und ich werde versuchen, zu klären.

Viel Glück! // Eric Johansson

Answer 3

Ich denke, Sie mischen 2 verschiedene Aspekte, Quellcodeverwaltung und Bereitstellung. Nur weil Sie alle Ihre Dateien in einem einzigen Repository haben, bedeutet dies nicht, dass sie auf diese Weise bereitgestellt werden müssen. Es ist auch fraglich, ob Sie direkt mit der Quellcodeverwaltung oder stattdessen mit einem Build/Deploy-Skript, das eine beliebige Anzahl von Konfigurationen verarbeiten könnte, bereitstellen möchten.

Auch das Hosting von statischen Dateien auf einer separaten Domain lohnt sich nur auf stark frequentierten Webseiten. Sind Sie sicher, dass Sie nicht vorzeitig optimieren?