Estructura de carpetas populares para compilación

Question

Me pregunto cuál es la forma más popular o mejor para organizar sus activos de compilación y el código fuente dentro de un proyecto?

Answer 1

Personalmente utilizo

/client/projectname/trunk/source/Solution Name.sln 
/client/projectname/trunk/source/Project.One 
/client/projectname/trunk/source/Project.Two 
/client/projectname/trunk/source/Project.Three 
/client/projectname/trunk/source/SQL/ 
/client/projectname/trunk/source/SQL/SomeScript.sql 
/client/projectname/trunk/libraries 
/client/projectname/trunk/resources/Nunit 
/client/projectname/trunk/resources/LLBLGEN 
/client/projectname/trunk/documentation 
/client/projectname/trunk/builds 

Funciona bien para nosotros, pero no creo que es la mejor. Si se trata de .NET también se puede echar un vistazo a treesurgeon Lo describen a sí mismos como:

¿Alguna vez ha pasado unos días la creación de un nuevo árbol de desarrollo? ¿Alguna vez has pasado varios días armando varios árboles de desarrollo? ¿Has pasado semanas intentando perfeccionar todos tus árboles de desarrollo usando un conjunto de mejores prácticas?

Si la respuesta a cualquiera de las respuestas anteriores es 'sí', ¡entonces te gustará Tree Surgeon!

Tree Surgeon es un generador de árbol de desarrollo .NET. Simplemente déle el nombre de su proyecto, y configurará un árbol de desarrollo para usted en segundos. Más que eso, su nuevo árbol tiene años el valor de la experiencia acumulada de ingeniería acumulación construido en el derecho.

Answer 2

por ejemplo, uso lo siguiente para mis proyectos de estilo .Net;

/build/reports - reports and logs from the build process 
/build/artifacts - all output of the build process is copied here 
/src/ - all solution source code 
/lib/ - 3rd party or other build dependencies 
/tools/... - all other helper tools used in the build process 
/tools/nant - example tool 
/tools/nunit - example tool 
/myProject.sln - visual studio solution file (or other IDE) 
/default.build - nant build file 

Answer 3

Como estoy trabajando sólo en proyectos de Java, y todos ellos son "Mavenized", yo uso el conventions defined by Maven for the project structure.

Básicamente:

project 
    src/main/java  --> source files 
    src/main/resources --> resources files (*.xml, *.properties, etc.) 
    src/test/java  --> source files for tests. 
    src/test/resources --> resources files for tests. 

Answer 4

En general:

src/  - source files 
src/tests - unit tests 
doc/  - documentation 
res/  - static resources (textures, locale database, level definitions etc) 
build/ - tools needed to build the system 
      project specific libraries and compilers 
Makefile - the makefile (make, test, clean etc) 

Answer 5

me gusta la forma en que el IDE Netbeans organiza proyectos. Simplemente inicie un nuevo proyecto y configurará un árbol de desarrollo predeterminado y un script ant.

Answer 6

tengo

/src - source files (test files are within a package 'test' here, or 'test' subpackage of what is being tested) 
/lib - required libraries 
/doc - text documentation and development notes 
/build - where we build (each separate build item within a subfolder here) 
/conf - configurations (each config, production, test, developer, etc gets a folder in here, and when building Jars and Wars the correct set is copied across) 
/extras - other stuff 
/extras/resources - resources that should be included within generated Jars, e.g., icons 

con

/websites - Web related content and configurations (each website in its own folder here) 
/websites/$site/webcontent - All the web content here 
/websites/$site/conf - website related configuration files here (instead of /conf) 
/websites/$site/build.xml - ANT build script for website that creates a war, etc 

(remember you might have an admin site and a public site for a single project, hence the multi-site configuration within a single project, or even site v1 and site v2, etc) 

Al final, usted tiene que ser un poco flexible en función del proyecto en sí, y si se utiliza ANT o Maven. Yo uso ANT, y pongo los scripts ANT en/build, pero han aparecido en otros proyectos (como en/websites/para algunos).

Answer 7

Esta organización de carpetas representa la evolución de xLim concepts.

Puede consultarlo en this open source project.

Build   - ignored from version control 
    Artifact  - build artifacts (grabbed by CC.NET from here) 
    Package  - generated zip or install packages 
    Test   - all assemblies for unit tests 
    Help   - autogenerated documentation 
Resource 
    Build   - plugins and extensions for NAnt/MSBuild 
    Library  - 3rd party dependencies 
    Tool 
    FxCop 
    ILMerge   
    NCover 
    NCoverExplorer 
    NUnit 
    SHFB 
    Wix 
Samples 
    SampleProject1 
    SampleProject2 
Source 
    Project1 
    Project2 

    GlobalAssemblyInfo.cs 
    VersionAssemblyInfo.cs - integration server updates this one 

Test 
    Project1.Tests 
    Project2.Tests   

Solution.build  - primary build file 
Solution.ccnet  - CruiseControl adapter for the build file 
Solution.sln   - Visual Studio 

go.cmd    - shortcut for launching the build file locally 
readme.txt   - licenses and overview 
SharedKey.snk   - for strong naming 

Answer 8

Para mí, depende del tamaño del proyecto. Para proyectos pequeños, encuentro que un directorio de proyecto con un único directorio Makefile,/src y/include funciona bien.

Answer 9

Para proyectos .NET, marque ProjectScaffold y analice en este gist.