workflow PHP - best practice

[Sven Rautenberg]

Moin!

meine Frage ist, wie ich am besten meinen Workflow einrichten soll. Vielleicht hat jemand Tips für mich.

auf einem remotehost arbeite ich über ssh an einem projekt. Die Dateien bearbeite ich via Notepad++ direkt auf dem remote development server. Von da ab deploye ich das Zeug über mercurial ins Livesystem. Meine Frage ist nun:

Remote ist immer eher doof, weil Netzverbindungen nun mal auch abbrechen können, aus diversen Gründen. Und sie sind langsamer, als lokales Arbeiten - das kann im Zweifel echt nerven.

ich möchte auf Eclipse oder eine andere IDE umsteigen und nicht mehr die Dateien direkt bearbeiten. Wie machen das die Profis? Soll ich mir lokal eine identische Umgebung erschaffen und die Dateien, wenn alles läuft, via SCP oder FTP auf den dev-Server schieben? Oder gibt es eine Möglichkeit, Eclipse so zu konfigurieren, dass die Dateien gleich via FTP hochgeladen werden, ähnlich wie bei Notepad++?

Ja, lokal eine Umgebung wäre eine gute Idee. Gern auch als virtuelle Maschine, die dadurch dann ein beliebiges, idealerweise identisch zum Produktivserver gestaltetes Betriebssystem hat, inkl. der dazu notwendigen Serversoftware und PHP-Version.

Außer dem Produktivserver kann man sich noch beliebig viele schöne Server ausdenken, die vorher aktiv sind, wie z.B.

• Staging-Server: Auf den wird die Software eingespielt und geprüft, bevor dieser Server zum Produktivserver wird (und die aktuell produktiven Server vom Netz gehen und wieder neue Staging-Server sind, bzw. als Rollback-System zur Verfügung stehen, falls das Update doch irgendwo Probleme macht).

• Test-Server: Für die QA, die auf diesen Systemen die Abnahme der Software macht.

• Development-Server: Zur Integration mehrerer Entwicklungszweige gibts einen zentralen Development-Server, der genau wie alle anderen Server möglichst identisch zur produktiven Umgebung ausschaut, aber eventuell weniger leistungsfähige Ressourcen hat.

• Lokaler Development-Server: für den individuellen Entwickler - auf diesem System kann er alles mögliche kaputt machen und neu erschaffen, ohne seine Kollegen damit zu nerven.

Außer auf dem lokalen Entwicklungsserver werden alle anderen Server nur aus dem Versionsverwaltungssystem befüllt, oder es werden zentral Softwarepakete geschnürt, die dann auf die Umgebung getan werden.

Vorteil: Wenn man aus Versehen vergisst, eine Datei einzuchecken, dann wird das System nicht korrekt funktionieren, wenn man die Version aus der Versionskontrolle auf den Development-, Test- oder Staging-Server spielt - und das wird hoffentlich bemerkt.

Natürlich ist es verlockend, als einziger Entwickler nebenbei zwar Versionskontrolle zu benutzen, aber dann die Dateien einfach allesamt auf den neuen Server zu tun.

Auf der anderen Seite ist zum lokalen Entwickeln unheimlich wichtig, dass man sehr schnell das Ergebnis einer Änderung sieht. Also Speichern - Neu laden - fertig. Schneller geht nicht, und genau so schnell muss die lokale Lösung sein können (oder noch schneller, wenn die eigene IDE das anbietet).

- Sven Rautenberg