[sahnemuh]

Hallo MGI,

ich bin derzeit in der glücklichen Lage mir einen sinnvollen, neuen Entwicklungsworkflow für kommende Projekte einfallen zu lassen. Ziel ist es die Qualitätssicherung sinnvoller zu handhaben und im Zuge dessen einige Altlasten technischer bzw. infrastruktureller Natur über Bord zu werfen. Ich würde gerne ein paar Schlagworte in den Raum werfen und hätte Interesse an einer regen Diskussion mit Menschen, die eventuell mit dem ein- oder anderen Tool (oder bestenfalls allen in Kombination) bereits zu tun hatten.
Die Ausgangslage ist folgendermaßen: Wir versionieren unsere Projekte derzeit noch mit einem recht altertümlichen, propertiären scm. Jeder benutzt eine andere IDE und es gibt teilweise je kunde historisch gewachsen unterschiedliche Bug-Tracking Systeme.
Unsere Projekte sind meistens zwar größer und beeinhalten auch echte "Software Entwicklung (PHP, eigenes Framework basierend auf eZ Components oder wahlweise ZEND)", sind aber zumeist eher "frontendlastig", daher klammere ich Themen wie standardmäßige Unit-Tests, Selenium etc. mal vorsichtig aus (auch dafür gibt es aber mitunter Bedarf).

Meine Idealvorstellung ausgehend von "vom Kunden kommt konkreter Auftrag XY" sieht folgendermaßen aus:
- Aufsetzen eines Ticketing-Systems für das Projekt (Derzeit auf meinem Radar: Jira, ActiveCollab)
- Als Entwicklungsumgebung kommen Eclipse (für Frontend+Aptana) oder PhpStorm (für Frontend WebStorm) zum Einsatz
- Als SCM hätte ich gerne GIT
- Ich hätte beides gerne in die IDE integriert (z.B. MyLyn und entsprechende konnektoren + GIT-Integration)
- Entwickelt wird lokal (ist derzeit auch der Fall), Als Webserver läuft Apache (über WampServer wegen multipler Apache/PHP Versionen, Entwicklungsrechner sind alle Windows Kisten)
- Browserchecks über lokal installierte Browser + VMs (IE) für Anwendungen / JS + Adobe Browserlabs für allgemeines Layout testen
- Es gibt einen internen Server auf den "gepusht" wird. Dieser dient auch zur internen Qualitätssicherung.
- Nach dem Fertigstellen einer Aufgabe in Form eines Tickets wird dieses durch den jeweils Verantwortlichen (internen) Qualitätsgesichert. Das Ticket kann nicht durch den Bearbeiter geschlossen werden
- Ist die Qualitätssicherung abgeschlossen wird das Projekt / der Bugfix / das Feature per GIT auf einen Staging-Server beim Kunden deployed um nach Abnahme dann ebenfalls automatisiert (Capistrano) auf den Live-Server zu wandern. Alle "externen" Server sind jeweils absolute "No-Go" Zonen für FTP/SSH/Mal eben was korrigieren Aktionen

Meine Frage: Wie kriegt man einen solchen Workflow möglichst sinnvoll (Verzahnung: Tickets und SCM in IDE) und schmerzfrei aufgesetzt? Ist meine "Wahl der Waffen" O.K.? Gibt es Alternativen? Habe ich etwas vergessen?

Danke schon mal im Voraus!

€: Ach ja. Ich habe noch 1-2 Anforderungen / Fragen zu einigen Tools vergessen:
- Das Ticketsystem sollte "Interne" und "Externe" Tickets unterstützen (Kunde soll Zugriff bekommen), Tickets müssen per Mail erstellt werden können
- Das Ticketsystem sollte intern in einer DMZ gehostet werden (Clouddienste also ausgeschlossen)
- Adobe Browserlabs ist nicht gesetzt... gibt es da bessere Alternativen?
- Über WampServer bin ich mir auch unsicher Zend ist "Oversized", XAMPP geht garnicht... ich brauche irgendwas, was gleiche Vorraussetzungen für unterschiedliche PHP/Apache Versionen schafft

[bacon]

[Elorie]

Eclipse hat Plugins die GIT relativ zufriedenstellend einbinden, bei den anderen beiden kann ich das nicht beurteilen, würde aber auf jeden Fall das Repo auf nem lokalen oder externen Datenserver haben und nicht nur auf den Rechnern...

[remote]

Also was IDEs betrifft sind die von JetBrains ein absoluter no-brainer.
PHP IDE + HTML/JS/XML ---> PHPStorm. Mit weitem Abstand die kommerzielle Software mit dem besten Preis-/Leistungsverhältnis auf meinem Rechner.

Für die IDE gibt es auch ein Jira Plugin, so dass Tickets direkt in der IDE bearbeitet werden können.
Was das Deployment betrifft, ist mir demletzt in Essen beim Drupalcamp der Workflow von bright solutions über den Weg gelaufen - fand ich ganz sympatisch, wenn auch für uns etwas zuviel des Guten.

[sahnemuh]

[sahnemuh]