Creazione di un'egemonia di team di sviluppo indipendente dalla piattaforma

Question

Creazione di un'egemonia di team di sviluppo indipendente dalla piattaforma

Naviga le tue risposte

#1 da (3 voti)
#2 da (2 voti)

9

Lavoro in un'azienda in cui disponiamo di un sacco di competenze diverse nel team di sviluppo.

Facciamo tutto quanto segue (generalmente orientato al web):

. NET (MVC, Umbraco, ASP.NET, Surface)
Java (Spring, Hibernate, Android)
PHP (Zend, Code igniter)
Actionscript 3
AIR
Objective-C
HTML / Javascript (ovviamente)

Stiamo cercando di ottimizzare il nostro processo di sviluppo.

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

Ciò che voglio è qualcosa di simile a Maven che ci fornirà una struttura standard per i modelli di progetto che funziona per la maggior parte dei progetti per consentire alle persone di gruppi diversi di spostarsi facilmente tra i progetti.

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

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

team

posta Rob Stevenson-Leggett 29.09.2010 - 11:16

fonte

2 risposte

2

Attualmente utilizziamo diverse lingue nel nostro progetto: C ++, Java, Ruby, Perl, OCaml, Shell, PHP e JavaScript. E non abbiamo alcun problema 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. A volte chiamano altri sistemi di build, se necessario (ad esempio, invocano Java's Ant per creare il codice Java). Se questi sistemi di build sono legati a un layout specifico, non è un problema, perché ogni componente ha il suo, e potrebbe essere ottimizzato per soddisfare i requisiti del sistema di generazione.

L'idea chiave era di mantenere ogni componente separatamente dagli altri. All'interno della sua directory abbiamo semplicemente archiviato i file come pensavamo sarebbe stato utile per questo particolare componente. Non abbiamo grandi blob come 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.

risposta data 09.10.2010 - 17:22

fonte

Leggi altre domande sui tag team

Quale problema pratico deriva dalla mancanza di macro igienici in Clojure? Convenzione su dove dichiarare module.exports su file Javascript

score 3 · Accepted Answer

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

Come per gli altri linguaggi, suggerisco di applicare la stessa struttura supportata da Maven (tutte le fonti sotto src/language/main , ecc.) e quindi scrivere i plugin Maven per crearli o almeno scrivere modelli generici "Makefile" che supportano questo struttura fuori dalla scatola.