Stworzenie hegemonii platformy rozwoju agnostycznego

9

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?

team Rob Stevenson-Leggett
źródło
Jak to by działało? Jeśli ktoś musi zbudować aplikację internetową, czy musi określić język, czy też chcesz zmusić wszystkie języki do korzystania z tej samej struktury, nawet jeśli nie jest to idealne rozwiązanie dla tego języka? Na przykład ustrukturyzowanie moich plików javascript, tak jak robię Java lub C #, byłoby uciążliwe.
James Black

Odpowiedzi:

3

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.

Aaron Digulla
źródło
2

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.

P Shved
źródło