Création d'une hégémonie d'équipe de développement indépendante de la plateforme

9

Je travaille dans une entreprise où nous avons beaucoup de compétences différentes dans l'équipe de développement.

Nous faisons tout ce qui suit (généralement orienté vers le Web):

  • .NET (MVC, Umbraco, ASP.NET, Surface)
  • Java (Spring, Hibernate, Android)
  • PHP (Zend, allumeur de code)
  • Actionscript 3
  • AIR
  • Objectif c
  • Html / Javascript (évidemment)

Nous essayons de rationaliser notre processus de développement.

Nous avons actuellement un serveur TeamCity qui construit et déploie des projets .NET avec msbuild / msdeploy / nant.

Ce que je veux, c'est quelque chose comme maven qui nous donnera une structure de modèle de projet standard qui fonctionne pour la plupart des projets pour permettre aux personnes de différentes équipes de se déplacer facilement entre les projets.

Actuellement, cela fonctionne sur une seule plate-forme, car nous avons tendance à faire les choses de manière standard pour cette plate-forme (tant que certaines personnes ont été impliquées), mais je veux utiliser quelque chose comme maven pour normaliser la façon dont un projet est conçu et construit.

Quelqu'un a-t-il déjà essayé quelque chose comme ça? Expériences? Livres?

team Rob Stevenson-Leggett
la source
Alors, comment cela fonctionnerait-il? Si quelqu'un a besoin de créer une application Web, devra-t-il spécifier une langue, ou voulez-vous forcer toutes les langues à utiliser la même structure, même si elle n'est pas idéale pour cette langue. Par exemple, structurer mes fichiers javascript comme je le fais Java ou C # serait une douleur.
James Black

Réponses:

3

Quant à .NET, il existe trois projets pour porter Maven. Voir cette réponse sur stackoverflow.com. Aussi cet article wiki pourrait être utile.

En ce qui concerne les autres langues, je suggère d'appliquer la même structure que Maven prend en charge (toutes les sources ci src/language/main- dessous , etc.), puis d'écrire des plugins Maven pour les construire ou au moins d'écrire des modèles génériques "Makefile" qui prennent en charge cette structure hors de la boîte.

Aaron Digulla
la source
2

Actuellement, nous utilisons plusieurs langages dans notre projet: C ++, Java, Ruby, Perl, OCaml, Shell, PHP et JavaScript. Et nous n'avons aucun problème à les supporter tous. Parce que chaque composant a sa propre structure et disposition de répertoire . La construction est collée avec des Makefiles récursifs simples traités par GNU make. Ils appellent parfois d'autres systèmes de build, si nécessaire (par exemple, ils invoquent Java's Ant pour construire le code Java). Si ces systèmes de build sont liés à une disposition spécifique, ce n'est pas un problème, car chaque composant a le sien, et il pourrait être réglé pour répondre aux exigences du système de build.

L'idée clé était de garder chaque composant séparément des autres. Dans son répertoire, nous venons de stocker les fichiers car nous pensions qu'il serait utile pour ce composant particulier. Nous n'avons pas de gros blobs comme les src/répertoires qui contiennent, par exemple, tout le code d'une langue. De cette façon, nous n'avons rencontré aucun problème avec l'édition de code dans différents composants.

P Shved
la source