it-swarm.com.de

Wie füge ich der PHP / Web-Entwicklungsumgebung eine Versionskontrolle und einen separaten Entwicklungsserver hinzu?

Ich bin der Teamleiter einer kleinen Gruppe von Entwicklern. Mein Hintergrund liegt hauptsächlich in der Anwendungsentwicklung, und ich habe in größeren Gruppen gearbeitet, in denen die Versionskontrolle (SVN, Git usw.) verwendet wurde und sich als sehr nützlich erwiesen hat. Ich fange an, unsere Webentwicklung zu beaufsichtigen, die derzeit ein einsamer PHP-Entwickler ist. Wir werden jedoch bald einen zweiten PHP/Web-Entwickler hinzufügen. Gegenwärtig programmiert unser einsamer PHP-Entwickler die Dinge live (dh er nimmt Änderungen an einer PHP-Datei vor, lädt den neuen Code hoch und sieht, was passiert). Ich möchte dies ändern, da dies nur darum bittet, dass eine Katastrophe eintritt. Ich denke auch daran, seinem Prozess eine Art Versionskontrolle hinzuzufügen. Wir haben bereits einen SVN-Server, der für die Anwendungsentwicklung verwendet wird, daher möchte ich das irgendwie nutzen. Ich bin auf der Suche nach Ratschlägen, wie ich das am besten angehen und welche Änderungen vorgenommen werden müssen.

Sollen wir unseren vorhandenen Webserver für die Entwicklung verwenden? Wir könnten eine vollständige Kopie der vorhandenen Websites erstellen und diese Kopien auf Subdomains ablegen. Wir nehmen dann Änderungen an diesen Kopien vor und synchronisieren, wenn alles in Ordnung ist, die Unterdomänen mit den Hauptsites. Wenn dies ein guter Ansatz ist, welche Tools (dh Software) sind für die Synchronisierung am besten geeignet? Gibt es eine Software, die diese Änderungen auch auf den SVN-Server überträgt, während die Dinge auf dem Webserver synchronisiert werden? Je weniger Schritte an diesen Änderungen beteiligt sind, desto besser.

Oder wäre es besser, einen völlig separaten Server für die Entwicklung zu haben? Der Nachteil dabei ist die Wartung ... wir haben so gut wie kein Personal.

Jeder Rat wird sehr geschätzt. Die Web-/PHP-Entwicklung unterscheidet sich ein wenig von der Entwicklung Ihrer Standardanwendung (Java, C++ usw.), an die ich gewöhnt bin. Daher bin ich auf jeden Fall offen für Ideen, wie diese Abteilung am besten betrieben werden kann.

Danke, Harry

2
Harry Muscle

NIEMALS auf dem Produktionsserver arbeiten und "sehen, was passiert".

Machen Sie Ihr Team mit:

und verteilen Sie jedem eine Kopie dieses Buches, die ich wärmstens empfehlen kann: Continuous Delivery: Zuverlässige Softwareversionen durch Build-, Test- und Deployment-Automatisierung

Automatisieren Sie so viel wie möglich. Auslösetests, Linters, bauen ohne Aufwand. Erstellen Sie virtuelle Umgebungen für Entwicklung, Bereitstellung und Produktion. Mit virtuellen Umgebungen können Sie völlig neue Szenarien testen und Ihren Produktionsserver imitieren (suchen Sie beispielsweise nach "virtualbox headless", lesen Sie Artikel wie diesen ). Einmal eingerichtet, ist es wirklich nicht kompliziert, da Sie jeden Schritt mit einem Mausklick oder dem nächsten Commit orchestrieren.

Im Rahmen von Delivery gibt es eine Vielzahl von Tools, mit denen sich Dinge automatisieren lassen, sei es Capistrano oder Fabric (Python) oder natürlich Jenkins (Java).

Es gibt keine einheitliche Vorgehensweise (lesen Sie das Buch), aber Ihr Team wird den Prozess Schritt für Schritt verfeinern.

2
initall

Mein Team sitzt im selben Boot, und unsere Lösung bestand darin, einen lokalen Entwicklungsserver mit genau derselben Konfiguration (Apache conf/php.ini/versions) wie unser Bereitstellungsserver zu erstellen und SVN für die Versionskontrolle zu verwenden, wie wir es für herkömmliche Apps tun würden Entwicklung. Unser Entwicklungsserver verarbeitet auch SVN + Bugtracking-Systeme, so dass es viel einfacher ist, Fehler-/Feature-Anfragen zu bearbeiten. Da der Entwicklungs- und der Deployment-Server in der Konfiguration identisch sind, treten nur während des Deployments Übertragungsfehler auf.

1
Meki

Sie müssen selbst entscheiden, ob es sich lohnt, einen separaten Staging/Testing-Server nur für die Entwicklung zu haben.

Was die Tools betrifft, die Sie verwenden können, gibt es eine Vielzahl von CI-Tools und Deployment-Automatisierungstools, die mit SVN zusammenarbeiten. Capistrano ist ein recht leichtes Tool, das Ruby Kenntnisse erfordert, aber mit ihm können Sie Apps auf mehreren Servern ziemlich einfach bereitstellen/konfigurieren. Es ist auch möglich, ein Capistrano-Rezept zu schreiben, um es automatisch auf dem Staging-Server bereitzustellen, wenn ein neues Commit durchgeführt wird (mit einem SVN-Commit-Hook). Anschließend können auf der Staging-Site automatisch Funktionstests ausgeführt werden. Wenn die Tests erfolgreich sind, wird es automatisch auf bereitgestellt der Produktionsserver.

Mit Capistrano können Sie Ihren Staging- oder Produktionsserver auch problemlos auf eine beliebige frühere Version zurücksetzen und andere Aufgaben automatisieren (z. B. das Sichern der Site oder andere Wartungsaufgaben).

Ich hatte jedoch einige Probleme mit dieser Art der Einrichtung, da ich zur Vereinfachung einen Symlink für die Webroot-Site verwenden musste, da Capistrano Revisionen speichert und die aktive Revision verfolgt. Leider speichert Apache die Symlinks manchmal irgendwie im Cache, so dass Sie einige hässliche Hacks ausführen müssen (z. B. den Symlink löschen, wget verwenden, um einen Serverfehler auszulösen, und dann den Symlink neu erstellen), damit die Änderungen sofort wirksam werden.

Wenn Sie das Webroot auf den aktuellen Versionspfad ändern können, wird das Problem möglicherweise vermieden, aber Sie müssen den Webserver jedes Mal neu starten (wenn Sie Zugriff haben). Die Alternative ist die Verwendung von .htaccess und mod_rewrite, was möglicherweise weniger Arbeit bedeutet.

0
Lèse majesté
  • Ich würde niemals einen separaten Entwicklungsserver verwenden. Aus meiner Sicht wird dies dem Live-Server zusätzliche Komplexität bei der Bereitstellung verleihen. Da es sich um unterschiedliche Server handelt, kann sich das Verhalten nach der Live-Bereitstellung ändern und ein weiteres Desaster verursachen.
  • Klar, ich werde dringend empfehlen, ein Versionskontrollsystem zu verwenden. Ich bevorzuge "GIT", unabhängig von Programmiersprachen.
  • Vermutlich verwenden Sie einen VPS/dedizierten Server, sodass Sie den Versionskontrollserver selbst einrichten können.
  • Ich habe Erfahrung in der Verwendung von Entwicklungsservern und der Synchronisation mit Live-Anwendungen, es ist sehr einfach und effizient. Sie werden immer an Ihrer lokalen Umgebung arbeiten. Commit/Push für den Entwicklungszweig ausführen. Testen Sie es auf einer Subdomain (wie dev.yourdomain.com, mit grundlegender htaccess-Authentifizierung, damit Google es nicht crawlt). Nachdem es ordnungsgemäß getestet wurde, führen Sie einfach den Entwicklungszweig mit dem Master- (Live-) Zweig und Push zusammen, und fertig!
0
Rana