Creating a platform agnostic development team hegemony

Question

I work at a company where we have a lot of different skillsets in the development team.

We do all of the following (generally geared towards web):

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

We're trying to streamline our development process.

We currently have a TeamCity server that builds and deploys .NET projects with msbuild/msdeploy/nant.

What I want is something like maven that will give us a standard project template structure that works for most projects to allow people from different teams to move between projects easily.

Currently this works on one platform because we tend to do things in a standard way for that platform (as long as certain people have been involved) however I want to use something like maven to standardise how a project is laid out and built.

Has anyone tried anything like this before? Experiences? Books?

Answer 1

As for .NET, there are three projects to port Maven. See this answer on stackoverflow.com. Also this wiki article might be helpful.

As for the other languages, I suggest to apply the same structure that Maven supports (all sources below src/language/main, etc) and then either write Maven plugins to build them or at least write generic "Makefile" templates which support this structure out of the box.

Answer 2

Currently we employ several languages in our project: C++, Java, Ruby, Perl, OCaml, Shell, PHP and JavaScript. And we don't have any problems to put up with them all. Because each component has its own structure and directory layout. The build is glued together with simple recursive Makefiles processed by GNU make. They sometimes call other build systems, if necessary (for example, they invoke Java's Ant to build the Java code). If these build systems are tied to a specific layout, it's no problem, because each component has its own, and it could be tuned to fulfill the build system's requirements.

The key idea was to keep every component separately from the others. Inside its directory we just stored the files as we thought it would be useful for this particular component. We don't have large blobs like src/ directories that contain, for example, all the code for one language. This way we didn't experience any problems with editing code in different components.