Wie man große TYPO3 Projekte managt & entwickelt?

Question

Ich entwickle seit 2006 TYPO3-Projekte und Projekte werden größer und komplexer. Die Einrichtung einer einfachen CMS-Site mit einem Kontaktformular und einem Nachrichteneintrag ist Routine.

Gerade jetzt beendeten wir ein größeres Projekt: Eine Plattform für ein internationales Unternehmen mit unzähligen Erweiterungen: Anmeldung & Registrierung, Nachrichten, Auflisten Datenbankeinträge, dynamische Kontaktformulare, Umfragen & Statistiken, Intranet-Funktionen: Dokument & Download hochladen, mehrere Backend-Einstellungen für TCA-Modifikationen usw.

Die Projektmanager haben sich bei uns Entwicklern aufgeregt, weil manchmal, nachdem wir auf Funktion X fertig waren und später die Funktion Y auf den Dev-Server übertrugen, die Funktion X unterbrochen wurde. Dies stand im Zusammenhang mit TypoScript-Einstellungen, Erweiterungsabhängigkeiten, Versionsfehlern oder manchmal einfachen Programmierfehlern und Tippfehlern. Ich weiß, wie die letzteren kümmern, aber im Allgemeinen:

Aus Ihrer Erfahrung:

Wie können wir ein fehlersicheres System in TYPO3 zu entwickeln, in der alles in der Hand und Erweiterungen don funktioniert nicht in die Quere kommen? Mit anderen Worten: Wie können wir Funktionalitäten (Erweiterungen) sichern und isolieren - und diese Interdepency-Probleme vermeiden?

Wir arbeiten in einem DEV-Team mit zwei Entwicklern, und wir verwenden bereits:

• Subversion Repository
• Lokale DEV-Server für die Entwicklung & Prüfung
• Externe TypoScript Konfigurationsdateien, aufgeteilt in einzelne Dateien für jede Nebenstelle

Edit f oder Bountyhunters:

Was ich suche ist eine Best-Practice-Zusammenfassung, die diese Themen umfassen könnte:

• Allgemeine Workflow-Gewohnheiten
• Allgemeine Codierung Gewohnheiten
• Zuverlässigkeit unserer Subversion verpflichtet (oder Git)
• Komponententest (PHPUnit, Selen?)
• Bereitstellung (Ich habe noch nicht herausgefunden, wie automatisierte Bereitstellung kann er lp us)
• TypoScript Best Practices

Answer 1

Probleme, die wir in großen TYPO3-Projekten finden konnten, sind nicht viel anders als jedes Entwicklungsprojekt.

Allgemeine Praktiken:

• configure continuous integration platform mit continuous deployment tools;
• Testgetriebene Entwicklung mit automatisiertem Testen;
• robuste Architektur (dB, URL-Routing, ...);
• performance tests während der Entwicklung;
• Verwenden Sie Versionierung mit formatierten Kommentaren;
• verwenden leistungsstarke IDE als PHPSstorm, Eclipse, Netbeans;

Häufige TYPO3 Praktiken:

• Verwendung official API;
• folgen TYPO3 API code guideline;
• Verwenden Sie TYPO3 hooks, wo Sie können, wenn Sie die Logik von Core oder 3rd Party Erweiterungen ändern müssen;
• Verwenden Sie TypoScript constants, um Daten von der Logik in Ihrer Konfiguration zu trennen;

Weitere Referenzen:

• TYPO3 Best Practice Workshop
• TYPO3 Best Practices (de)
• TDD & Best Practices mit TYPO3 (de)

Extensions komplexe TYPO3-Installation verwalten helfen könnte:

• caretaker
• additional reports

Nutzung moderner Projektmanagementmethoden & Tools

• Scrum, Kanban, Lean Entwicklung Prinzipien
• Bugtrackers wie Redmine, Trac

Bücher:

• php|architect's Guide to Enterprise PHP Development

Answer 2

ich absolut recommmend mit PHPUnit für Unit-Tests starten, aber nicht vergessen, Unit-Tests wirklich darüber, wie Sie den Code in erster Linie zu erstellen, nicht in der Regel etwas, das Sie später hinzufügen. Aber natürlich, besser spät als nie.

Sie sollten einen Build-Server wie jenkins/hudson oder atlassian bamboo einrichten. Letzteres ist ziemlich nett und integriert sich in Zend Studio, was meiner Meinung nach die bessere Wahl ist, wenn man in PHP entwickelt.Im Allgemeinen werden die atlassian Produkte für Software-Projekte weit verbreitet. (Jira + confluence + greenhopper insbesondere)

Answer 3

Ich würde auch empfehlen, phpunit auf jenkins einzurichten - siehe http://jenkins-php.org/ als Vorlage, obwohl ich gutes Feedback über Teamcity gelesen habe. Dann, abhängig von dem Code, den Sie schreiben, Setup-Unit-Tests (für rohen PHP-Code, vielleicht ein bisschen mit Mocks), Integrationstests (API-und Modul-Konnektivität) und Systemtests (Selen).

Sobald Sie es nach jedem Build ausgeführt haben, können Sie sicher sein, dass mindestens die abgedeckten Funktionen funktionieren. Das Problem besteht jedoch darin, dass Sie mehr Zeit für das Schreiben von Tests und deren Unterstützung sowie für das Nachdenken über testbaren Code benötigen. Bedenken Sie auch, dass Sie nicht alles abdecken können - das ist nicht der Punkt. Sie müssen kritische Pfade abdecken.