Frage

Aus meiner Erfahrung eines der größeren Probleme stoßen wir während unserer webdevelopment Prozess ist, um unterschiedliche setups aktualisiert und und sicher auf verschiedenen Servern.

Meine Firma hat seine eigenen CMS, welches aktuell installiert across 100+ Servern.Im moment verwenden wir einen hack-ish FTP-basierten Ansatz, kombiniert mit upgrade-Skripts an den jeweiligen Standorten zu aktualisieren alle unsere CMS-setups.Die effiziente Verwaltung dieser setups wird zunehmend schwierig und riskant, wenn es mehrere benutzerdefinierte Module beteiligt.

  • Was ist der beste Weg, um mehrere setups von einer web-Anwendung, die sichere und up-to-date?
  • Wie Sie tun Sie es?
  • Gibt es irgendwelche spezielle Tipps in Bezug auf die Modularität in Anwendungen, in Auftrag zu erhalten die Flexibilität gegenüber unseren Kunden, aber immer noch in der Lage, um effizient zu verwalten Sie mehrere "Filialen" einer Anwendung?

Einige kontextbezogene Informationen:wir vor allem entwickeln, die auf dem LAMP-stack.Einer der wichtigsten Faktoren, der uns hilft zu verkaufen unsere CMS ist, dass wir die plugin so ziemlich alles, was unsere Kunden will.Dies kann von 10 bis zu 10.000 lines of custom code.

Eine Menge von benutzerdefinierten arbeiten, besteht aus sehr kleinen code-Stücken;die Verwaltung all dieser kleinen code-Stücken, die in Subversion scheint ziemlich mühsam und ineffizient zu mir (da liefern wir rund 2 websites jede Woche, das Ergebnis wäre ein Menge von Zweigen).

Wenn es etwas gibt, ich bin mit Blick, ich würde es gerne hören von Ihnen.

Vielen Dank im Voraus.


Roundup: erste von alle, Dank für alle Ihre Antworten.Alle diese sind wirklich hilfreich.

Ich werde wahrscheinlich verwenden Sie einen SVN-basierten Ansatz, wodurch benlumley's-Lösung am nächsten, was ich verwenden würde.Da die Antwort auf diese Frage unterscheiden sich möglicherweise in anderen usecases, ich werde akzeptieren, dass die Antwort mit den meisten Stimmen am Ende der Laufzeit.

Bitte prüfen Sie die Antworten ein und Stimme für diejenigen, die Sie denken, haben die meisten Mehrwert.

War es hilfreich?

Lösung

Ich denke, ein Versionskontrollsystem und den Teil der Codes „Verzweigung“, die Sie ändern müssen, könnte der beste Ansatz in Bezug auf Robustheit und Effizienz entpuppen.

Ein verteiltes Versions System am besten auf Ihre Bedürfnisse geeignet sein könnte, da es Ihnen erlauben würde, Ihre „Kern“ kennzeichnet sich nahtlos auf verschiedenen „Filialen“ zu aktualisieren, während einige Änderungen vor Ort zu halten, wenn es sein muss.

Edit: Ich bin mir ziemlich sicher, dass mit einem verteilten Version System bisher alles, was bis zu halten wäre weit weniger langweilig als das, was man zu erwarten scheint: Sie Änderungen halten Sie sind sicher, dass Sie sind gehen nie anderswo lokale brauchen, und der verteilte Aspekt bedeutet jede Ihrer bereitgestellten Anwendung von den anderen tatsächlich unabhängig ist und nur noch die Fix- Sie zu propagieren bedeuten, wird propagieren.

Andere Tipps

Ihre Anwendung Wenn die Anpassung beinhaltet viele kleine Teile des Codes zu ändern, kann dies ein Zeichen dafür sein, dass Design Ihrer Anwendung fehlerhaft ist. Ihre Bewerbung sollte eine Reihe von stabilem Kern-Code hat, Erweiterungspunkte für benutzerdefinierte Bibliotheken Stecker in der Fähigkeit Aussehen zu verändern Vorlagen, und die Fähigkeit, Verhalten zu ändern und installieren Plugins Konfigurationsdateien. Auf diese Weise brauchen Sie keinen separaten SVN Zweig für jeden Kunden. Vielmehr hält die Kern-Code und Erweiterung Plugin-Bibliotheken in der Quellcodeverwaltung als normal. In einem anderen Repository, erstellen Sie einen Ordner für jeden Kunden und hält alle ihre Vorlagen und Konfigurationsdateien gibt.

Vorerst Zweige SVN Erstellung möglicherweise die einzige Lösung sein, dass Sie Ihre geistige Gesundheit halten hilft. In Ihrem aktuellen Zustand ist es fast unvermeidlich, dass Sie einen Fehler gemacht und vermasselt Website eines Kunden machen werden. Mindestens mit Niederlassungen sind Sie garantiert eine stabile Codebasis für jeden Kunden haben. Die einzige Gotcha mit SVN Zweigen ist, wenn Sie eine Datei in einem Zweig verschieben oder umbenennen, ist es unmöglich, diese Änderung zu verschmelzen wieder auf den Stamm (man müßte es manuell tun).

Viel Glück!

EDIT: Ein Beispiel für eine gut gestaltete Anwendung alle Prinzipien verwenden ich oben beschrieben, finden Sie unter Magento E-Commerce . Magento ist die leistungsfähigste, erweiterbare und einfache Web-Anwendung anpassen ich bisher gearbeitet habe.

kann ich falsch sein, aber es scheint mir, was Aron ist nachdem es nicht Versionskontrolle. Versionierung ist groß, und ich bin sicher, sie verwenden es bereits, aber für Updates auf Hunderte von kundenspezifischen Installationen verwalten, müssen Sie etwas anderes.

Ich denke, etwas entlang der Linien eines Zweck gebauten Paketsystem . Sie werden jede Version eines Moduls wollen den Überblick über seine individuellen Abhängigkeiten zu halten und ‚garantiert Kompatibilitäten‘, und diese Informationen benutzen, um automatisch nur die ‚sichere‘ Module zu aktualisieren.

z. Lassen Sie uns sagen, dass Sie eine neue Version 3 des ‚Wiki‘ Modul aufgebaut haben. Sie wollen die neue Version auf allen Servern, auf denen Ihre Anwendung propagieren, aber Sie haben in der Wiki-Modul an einer der Schnittstellen Änderungen seit Version 2 nun für alle Standardinstallationen, das ist kein Problem, aber es würde brechen Installationen mit kundenspezifischen Erweiterungen auf der alten Schnittstelle. Ein gut geplantes Paket System würde sich darum kümmern.

die Sicherheitsfrage adressieren, die Sie in die digitalen Signaturen auf Ihrem Patches aussehen sollten. Es gibt viele gute Bibliotheken für Public-Key-basierte Signaturen, so gehen Sie einfach mit dem, was scheint der Standard für die gewählte Plattform zu sein.

Nicht sicher, ob jemand sagte dies, gibt es hier viele lange Antworten, und ich habe nicht lesen sie alle.

Ich denke, eine bessere Lösung für Ihre Versionskontrolle wäre Ihr CMS zu haben, in einem eigenen Repository und jedes Projekt in seinem eigenen auf seinem eigenen saß. (Oder alle diese könnten Unterordner innerhalb eines Repo sein i guess)

Sie können dann mit seinem Stamm (oder eine bestimmte Branche / Tag, wenn Sie bevorzugen) als svn: external in jedem Projekt, das es erfordert. Auf diese Weise werden alle Aktualisierungen, die Sie an das CMS machen kann zurück zu seinem Repository übergeben werden und wird in anderen Projekten gezogen werden, wie und wann sie aktualisiert werden Svn (oder die externe wird svn: Schalter ‚ed).

Im Rahmen macht dies einfacher, müssen Sie das CMS, um sicherzustellen, und die benutzerdefinierten Funktionen in verschiedenen Ordnern sitzen, so dass SVN Äußerlichkeiten richtig funktionieren.

IE:

project
 project/cms <-- cms here, via svn external
 project/lib <-- custom bits here
 project/www <-- folder to point apache/iis at

(Sie cms und lib unter dem www-Ordner haben könnte, wenn erforderlich)

Damit können Sie Verzweigen / Markieren jedes Projekt, wie Sie möchten. Sie können auch die SVN-Schalter. Extern Lage auf einer pro Zweig / Marke Basis

Im Hinblick auf die immer Veränderungen leben, würde ich vorschlagen, dass Sie sofort von ftp loszuwerden und rsync oder svn checkout / export verwenden. Beide arbeiten gut, die Wahl liegt ganz bei Ihnen.

Ich habe die meisten Erfahrungen mit dem rsync Weg bekommt, einen SVN-Export auf den Server rsyncing. Wenn Sie diesen Weg gehen, schreiben Sie einige Shell-Skripte, und Sie können eine Test Shell-Skript erstellen Sie die Dateien zu zeigen, es ihnen auch ohne das Hochladen laden wird, die Option -n verwenden. Ich benutze im Allgemeinen ein Paar von Skripten für jede Umgebung - ein einen Test, und man es eigentlich zu tun

.

Shared Key-Authentifizierung, so dass Sie Uploads kein Passwort benötigen kann auch nützlich sein zu senden, je nachdem, wie sicher der Server den Zugriff gegeben werden soll.

Sie können auch eine andere Shell-Skript zu tun Bulk-Upgrades, Wartung, die einfach das entsprechende Shell-Skript wollen für jedes Projekt, das Sie ruft aktualisieren.

Haben Sie sich Drupal? Nein, nicht zu implementieren und zu ersetzen, was Sie haben, aber zu sehen, wie sie Behandlung von Anpassungen und ortsspezifische Module?

Im Grunde ist es eine „Sites“ Ordner, die ein Verzeichnis für jede Seite hat Sie Hosting. Innerhalb jeder Ordner ist eine separate settings.php, die Sie eine andere Datenbank angeben können. Schließlich können Sie (optional) haben „Themen“ und „Module“ Ordner innerhalb von Standorten.

Auf diese Weise können Sie ortsspezifische Anpassungen von einzelnen Modulen und begrenzen bestimmte Module auf den verlinkten Seiten tun. Als Ergebnis erhalten Sie mit einer Website auf, dass die überwiegende Mehrheit der alles vollkommen identisch ist und nur die Unterschiede dupliziert bekommen. Kombiniert man dies mit der Art und Weise sie behandelt Upgrades und Updates und Sie könnten ein tragfähiges Modell haben.

Erstellen Sie in den Code ein Selbstaktualisierungsprozess.
Es wird nach Updates suchen, und führen Sie sie wann / wo / wie Sie es für den Client konfiguriert haben.

In Kürze erhalten Sie haben eine Art von einer Liste von Modulen (benutzerdefinierten oder nicht), die vor dem Roll-out mit dem neuen Build getestet werden müssen, erstellen. Wenn ein Update bereitstellen werden Sie diese getestet und integriert korrekt gewährleisten müssen. Hoffentlich ist Ihr Design kann damit umgehen.

Updates sind im Idealfall ein paar wichtige Schritte.

  1. a) Backup so können Sie wieder aus. Sie sollten wieder heraus der Lage sein, die gesamte Aktualisierung jederzeit möglich. Damit, das bedeutet, dass ein lokales Archiv zu erstellen der Anwendung und Datenbank zuerst.

    b) Aktualisieren von Monitoring-Prozess -. Lassen Sie das CMS-System Telefon zu Hause für einen Neubau suchen

    c) Zeitplan Aktueller Stand Verfügbarkeit - Die Chancen stehen Sie nicht das Update soll die zweite ausführen es verfügbar ist. Dies bedeutet, dass Sie einen cron / Agenten irgendeine Art haben zu erstellen, das System-Update automatisch in der Mitte der Nacht zu tun. Sie können auch Kundenanforderungen berücksichtigen am Wochenende zu aktualisieren oder an bestimmten Tagen. Sie können taumeln auch Ihr Updates Ausrollen, so dass Sie nicht mehr als 1000 Kunden in 1 Tag aktualisierten und technischen Support Hölle bekommen. Versetzte Roll-out von einer Art könnte für Sie von Vorteil sein.

    d) In dem Wartungsmodus die Website aktualisieren -. Schieß den Standorts in dem Wartungsmodus

    e) SVN checkout oder Pakete für den Download - im Idealfall können Sie über svn checkout bereitstellen, und wenn nicht, Setup des Servers svn erzeugt Pakete in ein Archiv zu liefern, die auf den Client-Standorten eingesetzt werden kann.

    f) Bereitstellen DB Scripts - Sichern Sie die Datenbanken, aktualisieren Sie sie, füllen sie

    g) Update-Site-Code -. All das Werk für einen Schritt

    h) Führen Sie einige Tests auf sie. Wenn Ihr Code Selbsttests eingebaut hat, wäre es ideal.

Hier ist, was ich Tue...

Client-spezifische include-Pfad

  • Shared, common code shared/current_version/lib/
  • Site-spezifische code wird in Kunden/foo.com/lib
  • Der include-Pfad gesetzt, um zu zählen, aus der Kunden/foo.com/lib, und dann share/lib
  • Das ganze ist in einer version control system

Dadurch wird sichergestellt, dass der code verwendet die freigegebenen Dateien, wo immer möglich, aber wenn ich das überschreiben einer bestimmten Klasse oder eine Datei für einige Grund, das ich schreiben kann eine client-spezifische version in Ihren Ordner.

Alias-gemeinsame Dateien

Meine virtuelle host-Konfiguration wird enthalten eine Zeile wie

Alias /common <path>/shared/current_version/public_html/common

Das erlaubt eine gemeinsame UI-Elemente, icons, etc. werden gemeinsam über Projekte

Tag der common code mit jeder Seite release

Nach jedem Website-release, ich-tag-der common code durch erstellen einer Verzweigung effektiv einfrieren diesem Punkt in der Zeit.Dies ermöglicht es mir, bereitstellen /shared/version_xyz/ auf den live-server.Dann kann ich einen virtuellen host mit einer bestimmten version des gemeinsame-Dateien, oder lassen Sie Sie deutete auf die current_version wenn ich es wollen zu Holen die neuesten updates.

Haben Sie bei Tools sah wie Puppet (für die Systemverwaltung inkl. App-Bereitstellung) oder < a href = "http://www.capify.org/" rel = "nofollow noreferrer"> Capistrano (Bereitstellung von Anwendungen in RubyOnRails aber nicht auf diese beschränkt)?

Eine Möglichkeit wäre, ein schreibgeschützte Version Control System (Subversion) einzurichten. Sie könnten Zugriff auf das Repository in Ihr CMS integrieren und die Updates über ein Menü aufrufen, oder automatisch, wenn der Benutzer eine Wahl über ein Update haben, nicht wollen (könnte von entscheidender Bedeutung sein). ein Versionskontrollsystem würden Sie erlauben auch verschiedene Zweige leicht zu halten

Wie Menschen haben bereits erwähnt, dass die Versionskontrolle verwenden (ich ziehe Subversion aufgrund Funktionalität) und Verzweigung wäre die beste Option sein. Eine weitere Open-Source-Software zur Verfügung, auf Source genannt CruiseControl-. Es ist erstaunlich, konfigurieren Sie CruiseControl- mit Subversion in sach eine Art und Weise, dass jeder Code-Änderung oder eine neue Code hinzugefügt in serversion, Tempomat automatisch wissen und wird für Sie bauen. Es wird Ihre Hölle Zeit sparen.

Ich habe die gleiche Art und Weise in meiner Firma getan. wir haben vier Projekte und müssen dieses Projekt auf verschiedenen Servern bereitstellen. Ich habe Setup cruiseconrol so, dass jede Änderung in der Code-Basis automatische Build auslöst. und ein anderes Skript, dass die Build auf dem Server bereitstellen. Ihr sind gut zu gehen.

Wenn Sie einen LAMP-Stack verwenden, würde ich auf jeden Fall drehen die Lösungen von Dateien in einem Paket von Ihrer Distribution und nutzen es für propagieren Änderungen. Ich empfehle für diese Angelegenheit Redhat / Fedora wegen RPM und es ist das, was ich habe Erfahrung auf. Auf jeden Fall können Sie auch jede Debian-basierte Distribution verwenden.

Vor einiger Zeit habe ich eine LAMP-Lösung ein ISP für die Verwaltung von Hosting-Server. Sie hatten mehrere Server Pflege von Web-Hosting zu nehmen, und ich brauchte eine Möglichkeit, die Änderungen von meinem Manager zu implementieren, da jede Maschine in sich geschlossene und hatte einen Online-Manager. Ich habe ein RPM-Paket die Lösungsdateien (PHP meistens) und einige der Bereitstellung Skripte enthält, die mit dem RPM runned.

Für die automatisierte Aktualisierung hatten wir unsere eigene RPM-Repository auf jedem Server in yum.conf gesetzt. Ich habe einen crontab Job den Server täglich mit dem neuesten RPMs von diesem vertrauenswürdigen Aufbewahrungsort zu aktualisieren.

Trustiness kann werden erreichen, weil Sie Vertrauen Einstellungen in den RPM-Paketen verwenden können, wie sie mit dem öffentlichen Schlüssel Datei Unterzeichnung und nur signierte Pakete akzeptieren.

Hm könnte es eine Idee sein, um Konfigurationsdateien hinzufügen? Sie schrieb, dass viele kleine Skript etwas tun. Nun, wenn Sie würde sie in den Quellen bauen und steuerte sie mit Konfigurationsdateien sollten nicht, dass „Leichtigkeit“ das?

Auf den anderen Seite mit Verzweigungen für jeden Kunden sieht aus wie ein exponentielles Wachstum zu mir. Und wie würden Sie „wissen“, welche Bereiche Sie etwas getan haben und vergessen Sie nicht zu Veränderungen in allen anderen Branchen auch „make“. Das sieht ziemlich hässlich zu mir.

Es scheint eine Kombination von Revisionskontrollen, Konfigurationsoptionen und / oder Bereitstellung Quittungen scheint eine „gute“ Idee zu sein .....

Mit, dass viele Variationen auf Ihrer Kernsoftware, ich glaube, Sie wirklich ein Versionskontrollsystem müssen an der Spitze zu bleiben über Aktuelles aus dem Kofferraum zu den einzelnen Client-Site drücken.

Also, wenn Sie Subversion denken langweilig sein würde, haben Sie einen guten Sinn bekommen für das, was die Schmerzpunkte sein werden ... Ich persönlich würde nicht Subversion für diesen empfehlen, es ist da nicht wirklich so gut an der Verwaltung und Verfolgung Geäst. Obwohl benlumley Vorschlag Äußerlichkeiten für Ihre Kernsoftware zu verwenden ist gut, das bricht, wenn Sie den Kern-Code für Ihre Kunden-Websites optimieren müssen.

Schauen Sie in Git für die Versionskontrolle, es ist gebaut für die Verzweigung, und es ist schnell.

Überprüfen Sie heraus Capistrano für Ihre Implementierungen zu verwalten. Es ist ein Ruby-Skript, oft mit Rails verwendet, aber es kann auch nicht-Rubin-Sites auf Remote-Servern für alle Arten von Dateiverwaltung verwendet werden. Es kann den Inhalt an das entfernte Ende durch verschiedene stragegies einschließlich ftp, scp, rsync, erhalten sowie automatisch die neueste Version aus dem Repository auschecken. Die netten Features, die es Haken sind für jeden Schritt des deploy Prozess Rückruf bietet (zB, so dass Sie Ihre Website-spezifische Konfigurationsdateien kopieren kann, die nicht in der Versionskontrolle sein könnte), und ein Log-System Release - durch Symlinks getan - so dass Sie schnell kann im Fall von Schwierigkeiten zu einer früheren Version zurücksetzen.

würde ich eine Konfigurationsdatei mit der Liste der Filialen und ihre gehosteten Lage empfehlen, dann mit einem Skript durch das ausführen, die jeder Zweig wiederum auscheckt und lädt die neuesten Änderungen. Dies könnte cron'd automatisch jede Nacht Updates zu tun.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top