Creazione di una piattaforma di sviluppo agnostico egemonia

Lavoro in un'azienda in cui abbiamo molti skillset diversi nel team di sviluppo.

Facciamo tutto quanto segue (generalmente orientato verso il web):

• .NET (MVC, Umbraco, ASP.NET, Surface)
• Java (Spring, Hibernate, Android)
• PHP (Zend, accenditore di codice)
• ActionScript 3
• ARIA
• Objective-C
• HTML / Javascript (ovviamente)

Stiamo cercando di semplificare il nostro processo di sviluppo.

Al momento disponiamo di un server TeamCity che crea e implementa progetti .NET con msbuild / msdeploy / nant.

Quello che voglio è qualcosa come Maven che ci fornirà una struttura standard di modello di progetto che funzioni per la maggior parte dei progetti per consentire alle persone di diversi team di spostarsi facilmente tra i progetti.

Attualmente funziona su una piattaforma perché tendiamo a fare le cose in modo standard per quella piattaforma (fintanto che alcune persone sono state coinvolte), tuttavia voglio usare qualcosa come Maven per standardizzare il modo in cui un progetto è strutturato e costruito.

Qualcuno ha provato qualcosa di simile prima? Esperienze? Libri?

Per quanto riguarda .NET, ci sono tre progetti per il port di Maven. Vedi questa risposta su stackoverflow.com. Anche questo articolo wiki potrebbe essere utile.

Per quanto riguarda le altre lingue, suggerisco di applicare la stessa struttura supportata da Maven (tutte le fonti sottostanti src/language/main, ecc.) E quindi scrivere plugin Maven per costruirli o almeno scrivere modelli "Makefile" generici che supportano questa struttura immediatamente.

Attualmente impieghiamo diverse lingue nel nostro progetto: C ++, Java, Ruby, Perl, OCaml, Shell, PHP e JavaScript. E non abbiamo problemi a sopportarli tutti. Perché ogni componente ha una propria struttura e layout di directory . La build è incollata insieme a semplici Makefile ricorsivi elaborati da GNU make. Talvolta chiamano altri sistemi di compilazione, se necessario (ad esempio, invocano la formica di Java per creare il codice Java). Se questi sistemi di compilazione sono collegati a un layout specifico, non è un problema, poiché ogni componente ha i suoi e potrebbe essere ottimizzato per soddisfare i requisiti del sistema di compilazione.

L'idea chiave era di mantenere ogni componente separatamente dagli altri. All'interno della sua directory abbiamo appena archiviato i file perché pensavamo che sarebbe stato utile per questo particolare componente. Non abbiamo BLOB di grandi dimensioni come le src/directory che contengono, ad esempio, tutto il codice per una lingua. In questo modo non abbiamo riscontrato problemi con la modifica del codice in diversi componenti.