Criando uma hegemonia independente da equipe de desenvolvimento da plataforma

Eu trabalho em uma empresa onde temos muitas habilidades diferentes na equipe de desenvolvimento.

Fazemos o seguinte (geralmente voltado para a Web):

• .NET (MVC, Umbraco, ASP.NET, Surface)
• Java (Spring, Hibernate, Android)
• PHP (Zend, ignitor de código)
• Actionscript 3
• AR
• Objetivo-C
• Html / Javascript (obviamente)

Estamos tentando simplificar nosso processo de desenvolvimento.

Atualmente, temos um servidor TeamCity que cria e implanta projetos .NET com msbuild / msdeploy / nant.

O que eu quero é algo como o maven que nos dará uma estrutura de modelo de projeto padrão que funcione para a maioria dos projetos, permitindo que pessoas de equipes diferentes se movam facilmente entre os projetos.

Atualmente, isso funciona em uma plataforma, porque tendemos a fazer as coisas de maneira padrão para essa plataforma (desde que algumas pessoas estejam envolvidas), no entanto, quero usar algo como maven para padronizar como um projeto é organizado e estruturado.

Alguém já tentou algo assim antes? Experiências? Livros?

Quanto ao .NET, existem três projetos para portar o Maven. Veja esta resposta em stackoverflow.com. Este artigo wiki também pode ser útil.

Quanto aos outros idiomas, sugiro aplicar a mesma estrutura que o Maven suporta (todas as fontes abaixo src/language/main, etc) e depois escrever plugins do Maven para construí-los ou, pelo menos, escrever modelos genéricos do "Makefile" que suportem essa estrutura imediatamente.

Atualmente, empregamos várias linguagens em nosso projeto: C ++, Java, Ruby, Perl, OCaml, Shell, PHP e JavaScript. E não temos problemas para aturar todos eles. Porque cada componente tem sua própria estrutura e layout de diretório . A compilação é colada com Makefiles recursivos simples processados ​​pelo make GNU. Às vezes, eles chamam outros sistemas de construção, se necessário (por exemplo, invocam o Ant do Java para criar o código Java). Se esses sistemas de construção estiverem vinculados a um layout específico, não há problema, porque cada componente possui o seu e pode ser ajustado para atender aos requisitos do sistema de construção.

A ideia principal era manter cada componente separadamente dos outros. Dentro de seu diretório, apenas armazenamos os arquivos, pois achamos que seria útil para esse componente em particular. Não temos blobs grandes como src/diretórios que contêm, por exemplo, todo o código de um idioma. Dessa forma, não tivemos problemas com a edição de código em diferentes componentes.