프로젝트 폴더를 어떻게 구성합니까? [닫은]

안녕하세요

여러분의 프로젝트 폴더 구성 방법을 알고 싶습니다.

한 번은 고객별로 정리할 것을 제안하는 상사가있었습니다.

Projects
|
|----Customer 1
     |---- A Cool Solution 1
           |---- source
                 |---- version1.0
                 |---- version1.1
           |---- docs
                 |---- analysis
                 |---- meetings
                 |---- manuals
|----Customer 2
|----Customer 3

내 친구가 기술을 통해 팀을 조직하라고 말했습니다.

Projects
|
|----.NET
     |---- C#
          |---- Customer 1     
                |---- A Cool Solution 1
                      |---- source
                            |---- version1.0
                            |---- version1.1
                      |---- docs
                            |---- analysis
                            |---- meetings
                            |---- manuals
|----Ruby
|----PHP

그리고 너? 프로젝트 폴더를 정리할 수있는 영리한 방법이 있습니까?

이것이 우리가 사용한 것입니다.

Projects
|
|----Customer A
     |---- Project 1
     |     |---- BuildControl       (CI/nAnt/Make/MSBuild files and config, etc)
     |     |---- Documentation      (In XML format so we can 'build' them)
     |     |---- Source
     |     |     |---- Component X
     |     |     |---- Component X.tests
     |     |     |---- Component Y 
     |     |     |---- Component Y.tests
     |     |---- Testing
     |     Project 1.sln      (Has folders as per project on-disk structure)
     |---- Project 2
     |---- Shared/Common components
|----Customer B
|----Customer C
|----<Our Company>
     |---- Internal Project A
     |---- Internal Library B

우리는 수년 동안 많은 다른 고객과 함께 여러 프로젝트에이 구조를 사용해 왔으며 매우 잘 작동합니다.

초기 제안과 매우 유사하지만 버전 관리를 사용하여 버전 관리를 관리합니다. 서버 리포지토리는 다른 것이 아니라 "고객 X-프로젝트 Y"로 이름이 지정됩니다. 이를 통해 일부 프로젝트에서 외부 계약자가 작업 할 수 있지만 버전 관리 루트에서 권한을 설정할 수 있으므로 다른 프로젝트에 액세스 할 수 없습니다.

모든 사용자는 자신의 (Windows) dev 시스템에서 원하는 위치로 작업 사본을 체크 아웃하고 SUBST 명령을 사용하여 드라이브 문자를 해당 위치에 맵핑합니다. 그렇게하면 빌드 파일 등에 하드 코딩 된 상대 경로를 모든 사람의 설정에서 사용할 수 있습니다. 예를 들어, 원하는 경우 공유 라이브러리에 대한 링크를 가질 수 있습니다. 우리는 보통이 버전을 달성하기 위해 버전 제어 링크 / 별칭을 사용합니다.

이 구조의 큰 장점 중 하나는 고객의 코드를 서로 분리 할 수 ​​있다는 것입니다. (a) 통합 목적으로 소스를 정기적으로 업데이트하고 (b) 외부 계약자가 코드의 선택된 부분을 작업하도록해야하는 경우에 유용합니다.

두 번째 제안은 둘 이상의 기술을 사용하는 복잡한 프로젝트에서는 잘 작동하지 않습니다.

나는 꽤 평평합니다.

/ 프로젝트

상자에 따라 약간의 변형이 있지만 그 뒤에는 프로젝트를위한 개별 폴더가 많이 있습니다. 어쨌든 소스 컨트롤에 실제 거래가 있기 때문에 이것은 임시 로컬 홈입니다.

나는 다음과 같이 느슨하게 보이는 구조를 가지고 있습니다.

~/
|-- Developer/
|   |-- Projects/
|   |   |-- Archives/
|   |   |-- Current/
|   |   |-- Work/
|-- Projects -> ~/Developer/Projects/Current

Archives더 이상 작업하지 않는 오래된 프로젝트가 포함되어 있습니다. Work작업 관련 프로젝트를 포함합니다. Current모든 현재 개발입니다. 그런 다음 홈 디렉토리에서으로 심볼릭 링크 Projects합니다 ~/Developer/Projects/Current. ~/Projects또한 일부 작업 프로젝트에 대한 심볼릭 링크를 포함합니다.

나는 또한 평평한 구조를 가지고 있습니다.

/ 프로젝트

Wyatt Barnett에 동의하면 실제 거래는 소스 제어에 그대로 있습니다.

어쨌든 많은 IDE가 최근 프로젝트 / 파일에 대한 바로 가기를 제공하기 때문에 어쨌든 폴더 구조에 특별한 것이 없어야한다고 덧붙이고 싶습니다. 그리고 어쨌든 누가 몇 개의 프로젝트를 수행합니까? 진실로 정의에 의해서만 최근의 것들입니다.

또한 어쨌든 최근 프로젝트 만 최상위 폴더에 추가합니다. 나는 모든 이전 및 완성 된 자료를 다음과 같이 보관합니다.

/ 프로젝트 / Old_stuff

또는 그런 것. 나는 일반적으로 다시 작업하지 않는 것을 보관합니다.

과거에는 Subversion 리포지토리를 사용하여 소스 문서를 저장했으며 리포지토리 조직에 대한 "프로젝트 마이너"규칙을 따랐습니다. 이는 크고 작은 조직 모두에서 매우 잘 작동하는 것으로 나타났습니다.

우리는 저장소 브랜치를 구성 할 것입니다. 다음과 같이 태그 및 트렁크 :

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

실제 소스 트리 자체에서 다음과 같은 구조를 사용합니다.

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct-+
        |                               +-build
        |                               +-doc
        |                               +-test
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

아이디어는 저장소의 구조를 사용하여 엔지니어링 팀 간의 의사 소통을 구조화하는 데 도움이되었습니다. 비즈니스의 고객 대면 부분과 다양한 기타 이해 관계자 및 도메인 전문가.

재치 : "프로젝트"디렉토리 중 하나에있는 소스 문서는 한 번만 사용됩니다 (그리고 돈을 버는 것). "productLines"디렉토리 중 하나에있는 문서는 해당 특정 라인의 제품이 판매 될 때마다 여러 번 돈을받습니다. "라이브러리"디렉토리 중 하나에있는 문서는이를 사용하는 모든 제품이 판매되는 횟수만큼 돈을 벌 수 있습니다.

비용 상각 개념을 명시 적으로 작성하고 비즈니스 전체에서 소스 문서 재사용에 대한 지원을 구축하는 데 도움이됩니다.

이상적인 세상에서 비즈니스의 일부에 직면 한 고객은이 구조를 사용하여 프리젠 테이션 및 기타 영업 자료를 저장하므로 개발자는 관련 제품 디렉토리와 함께 고객의 기대치가 무엇인지 확인할 수 있으며 고객이 직면 한 동료는 개발을 추적 할 수 있습니다 그들이 판매하는 기능과 제품에 대한 진행.

또한 빌드 자동화 도구가 작동 할 수있는 공통 구조가 있음을 의미합니다. (빌드 스크립트는 소스 트리에서 각 구성 요소의 빌드 방법을 지정하는 구성 파일을 찾는 "빌드"폴더를 찾습니다. 문서 생성 및 테스트에서 유사한 프로세스가 발생합니다). 다시, 이상적인 세상에서, 조직의 웹 사이트와 다른 마케팅 자료는 같은 방식으로 구축 될 수 있습니다.

하나의 마지막 메모로; 지속적인 통합 시스템은 빌드를 트리거해야한다는 것을 알고 있습니다. 정적 분석; 스모크 테스트 및 단위 테스트는 트렁크가 수정 될 때마다, "태그"분기가 수정 될 때마다, 그리고 "AUTOMATED"분기 분기가 수정 될 때마다 실행됩니다. 이러한 방식으로 개별 개발자는 중요한 기능인 IMHO와 같은 개인 지사와 함께 CI 시스템을 사용할 수 있습니다.

"문서 폴더"를 의미한다고 생각합니다. 고객 / 응용 프로그램 이후 "개발 및 유지 관리"의 끝 부분에서 부문별로 문서를 구성합니다.

예 : 프로젝트

• 재정적 인

  • 웹 애플리케이션

    • 앱 알파

       - source
       - functional docs
       - etc etc (testing, meeting with customer)
      

    • 앱 베타

       - functional docs
       - etc etc (testing, meeting with customer)
      

  • 데스크탑 소프트웨어
• 에너지 및 유틸리티
• 블라 블라