Stworzenie hegemonii platformy rozwoju agnostycznego

Pracuję w firmie, w której mamy wiele różnych umiejętności w zespole programistów.

Wykonujemy wszystkie następujące czynności (zazwyczaj ukierunkowane na sieć):

• .NET (MVC, Umbraco, ASP.NET, Surface)
• Java (Spring, Hibernate, Android)
• PHP (Zend, zapalnik kodu)
• ActionScript 3
• POWIETRZE
• Cel C
• HTML / JavaScript (oczywiście)

Staramy się usprawnić nasz proces rozwoju.

Obecnie mamy serwer TeamCity, który buduje i wdraża projekty .NET za pomocą msbuild / msdeploy / nant.

To, czego chcę, to coś w rodzaju maven, który da nam standardową strukturę szablonu projektu, która działa dla większości projektów, umożliwiając ludziom z różnych zespołów łatwe przemieszczanie się między projektami.

Obecnie działa to na jednej platformie, ponieważ mamy tendencję do robienia rzeczy w standardowy sposób dla tej platformy (tak długo, jak zaangażowane są pewne osoby), jednak chcę użyć czegoś takiego jak maven, aby ustandaryzować sposób projektowania i budowy projektu.

Czy ktoś próbował czegoś takiego wcześniej? Doświadczenie? Książki?

Jeśli chodzi o .NET, istnieją trzy projekty do przeniesienia Maven. Zobacz tę odpowiedź na stackoverflow.com. Pomocny może być również ten artykuł wiki .

Jeśli chodzi o inne języki, sugeruję zastosować tę samą strukturę, którą obsługuje Maven (wszystkie źródła poniżej src/language/mainitp.), A następnie albo napisać wtyczki Maven, aby je zbudować, albo przynajmniej napisać ogólne szablony „Makefile”, które obsługują tę strukturę od razu.

Obecnie w naszym projekcie korzystamy z kilku języków: C ++, Java, Ruby, Perl, OCaml, Shell, PHP i JavaScript. I nie mamy żadnych problemów z nimi wszystkimi. Ponieważ każdy komponent ma własną strukturę i układ katalogów . Kompilacja jest sklejona z prostymi rekurencyjnymi Makefile przetwarzanymi przez GNU make. Czasami w razie potrzeby wywołują inne systemy kompilacji (na przykład wywołują mrówkę Java w celu zbudowania kodu Java). Jeśli te systemy kompilacji są powiązane z określonym układem, nie stanowi to problemu, ponieważ każdy komponent ma swój własny i można go dostroić, aby spełniał wymagania systemu kompilacji.

Kluczowym pomysłem było trzymanie każdego elementu osobno od innych. W jego katalogu właśnie zapisaliśmy pliki, ponieważ uważaliśmy, że będą przydatne dla tego konkretnego komponentu. Nie mamy dużych obiektów blob, takich jak src/katalogi, które zawierają na przykład cały kod dla jednego języka. W ten sposób nie mieliśmy żadnych problemów z edycją kodu w różnych komponentach.