Come gestire e sviluppare grandi progetti TYPO3?

Question

Sto sviluppando progetti TYPO3 dal 2006 e i progetti stanno diventando più grandi e più complessi. Configurare un semplice sito CMS con un modulo di contatto e un elenco di notizie è tutto di routine.

In questo momento, abbiamo finito un progetto più grande: una piattaforma per una società internazionale con innumerevoli estensioni: Accesso & registrazione, notizie, sfogliare record di database, moduli di contatto dinamiche, indagini & statistiche, funzioni intranet: documento caricare & scaricare, diversi "tweaks" di back-end per modifiche al TCA, ecc.

I project manager si sono arrabbiati con noi sviluppatori, perché a volte, dopo aver terminato la funzione X e successivamente si è impegnata la funzione Y nel server di sviluppo, la funzione X è stata interrotta. Ciò era correlato a impostazioni typoscript, interdipendenze di estensione, errori di versioning o, a volte, errori di programmazione e errori di battitura. So come prendersi cura di questi ultimi, ma in generale:

Dalla tua esperienza:

Come possiamo sviluppare un sistema a prova di errore di TYPO3, dove tutto funziona in mano e le estensioni don si mettono sulla loro strada? In altre parole: In che modo possiamo proteggere e isolare le funzionalità (estensioni) ed evitare tali problemi di interdipendenza?

Stiamo lavorando in un team di sviluppo con due sviluppatori, e abbiamo già utilizziamo:

• Subversion Repository
• server di DEV locale per lo sviluppo & testare
• file di configurazione TypoScript esterne, divisi in singoli file per ogni estensione

Modifica f o Bountyhunters:

Quello che sto cercando è un best-practice-sintesi che potrebbe includere questi argomenti:

• generali abitudini del flusso di lavoro
• generali di codifica abitudini
• affidabilità della nostra eversione impegna (o Git)
• Unit testing (PHPUnit, selenio?)
• Deployment (non ho ancora capito come la distribuzione automatizzata può lui noi lp)
• TypoScript migliori pratiche

Answer 1

I problemi che potremmo trovare in grandi progetti TYPO3 non sono molto diversi da qualsiasi progetto di sviluppo.

pratiche generali:

• Configurare continuous integration platform con continuous deployment tools;
• Test Driven Development con test automatici;
• architettura robusta (dB, routing URL, ...);
• performance tests durante lo sviluppo;
• utilizza versionning con commenti formattati;
• utilizza potenti IDE come PHPStorm, Eclipse, Netbeans;
pratiche

comune TYPO3:

• uso official API;
• segue TYPO3 API code guideline;
• utilizzare TYPO3 hooks dove è possibile se è necessario modificare la logica delle estensioni Core o di terze parti;
• utilizzare TypoScript constants per separare i dati dalla logica nella configurazione;

Ulteriori riferimenti:

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

estensioni potrebbero aiutare a gestire complessa installazione TYPO3:

• caretaker
• additional reports

Usa gestione moderna metodologia di progetto & strumenti

• Scrum, Kanban, principi developement magre
• Bugtrackers come Redmine, Trac

Libri:

• php|architect's Guide to Enterprise PHP Development

Answer 2

ho assolutamente caldamente iniziare a utilizzare PHPUnit per unit test, ma ricordate unit testing è davvero su come si crea il codice, in primo luogo, non è di solito qualcosa da aggiungere in seguito. Ma ovviamente, meglio tardi che mai.

È consigliabile configurare un server di build come jenkins/hudson o atlassian bamboo. Quest'ultimo è abbastanza carino e si integra con lo studio zend che a mio parere è la scelta migliore quando si sviluppa in PHP.In generale i prodotti atlassian sono ampiamente utilizzati per progetti software. (Jira + confluenza + greenhopper in particolare)

Answer 3

Vorrei anche consigliare l'impostazione di phpunit su jenkins - vedere come modello, anche se ho letto un buon feedback su Teamcity. Quindi, a seconda del codice che si scrive, si eseguono i test delle unità di installazione (per codice raw php, forse un po 'di mock), test di integrazione (connettività API e modulo) e test di sistema (selenio).

Una volta eseguito dopo ogni generazione, si può essere certi che funzioni almeno coperte. Il problema è che passerai più tempo a scrivere test e il loro supporto, oltre a pensare al codice testabile. Ricorda anche che non puoi coprire tutto - non è questo il punto. Devi avere percorsi critici coperti.