프로젝트의 어떤 부분이 소스 코드 제어에 있어야합니까?

한 동료 개발자가 새로운 Drupal 프로젝트를 시작했으며 sysadmin은 "업데이트를 쉽게 스크립팅 할 수 있도록"사이트 / 기본 하위 디렉토리 만 소스 제어에 두도록 제안했습니다. 다소 모호한 주장을 제외하고는 또 다른 질문을 제기합니다. 어떤 파일이 소스 제어하에 있어야합니까? 그리고 큰 파일 덩어리를 제외해야하는 상황이 있습니까?

내 의견은 프로젝트의 전체 트리가 통제되어야하며 Drupal 프로젝트, 레일 또는 기타 다른 경우에 해당된다는 것입니다. 이것은 생각할 필요가없는 것처럼 보입니다. 작성하는 모든 사용자 정의 코드와 마찬가지로 프레임 워크 버전도 명확해야합니다.

즉, 나는 이것에 대해 다른 의견을 갖고 싶습니다. 모든 것을 통제하지 못한다는 주장이 있습니까?

소스 컨트롤에 포함되어야 하는 최소값 은 실행중인 버전의 프로젝트를 다시 만드는 데 필요한 모든 파일이라고합니다. 여기에는 데이터베이스 스키마를 설정하고 수정하는 올바른 DDL 파일도 포함됩니다. 물론 프로젝트를 빌드하고 실행하는 데 필요한 도구는 물론 소스 제어의 다른 파일 (예 : 소스 제어의 Java 파일에서 생성 된 JavaDoc 파일)에서 자동으로 파생 / 생성 할 수있는 도구도 있습니다.

태양 아래있는 모든 것을 소스 제어에 넣는 것이 가장 좋습니다.

• 암호

• 도서관

• 자원

• 스크립트 작성 / 배포

• 데이터베이스 생성 및 업데이트 스크립트

• 특정 문서

• 환경 별 구성 파일

소스 컨트롤에 넣지 말아야 할 유일한 것은 프로젝트의 빌드 아티팩트입니다.

나는 이렇게 말할 것이다;

• 빌드를 수행하는 데 필요한 모든 파일은 버전 제어에 들어갑니다.
• 빌드에 의해 생성 된 파일은 가능하지 않습니다.

트렁크 외부 어딘가에 도구 설치 패키지와 같은 큰 이진 파일을 넣는 경향이 있지만 여전히 버전 제어를 받아야합니다.

또한 모든 데이터베이스 코드를 소스 제어에 두는 것도 잊지 마십시오! 여기에는 원래 작성 스크립트, 테이블을 변경하는 스크립트 (소프트웨어가 사용하는 소프트웨어 버전으로 표시되어 있으므로 모든 버전의 응용 프로그램에 대해 모든 데이터베이스 버전을 다시 작성할 수 있음) 및 조회 테이블을 채우는 스크립트가 포함됩니다.

어려운 경험은 거의 모든 것이 소스 제어에 속 한다고 가르쳐주었습니다 . (내 의견은 독점적이며 때로는 찾기 어려운 도구가있는 독점적 인 하드웨어에서 임베디드 / 텔레콤 시스템을 개발하기 위해 10 년 반 동안 채색되었습니다.)

여기에 대한 답변 중 일부는 "이진을 소스 제어에 두지 마십시오"라고 말합니다. 그건 틀렸어요. 많은 타사 코드와 공급 업체의 많은 이진 라이브러리가있는 제품을 작업 할 때는 이진 라이브러리를 체크인하십시오 . 그렇지 않으면 언젠가는 업그레이드 할 것이며 문제가 생길 수 있습니다. 빌드 머신에 최신 버전이 없기 때문에 빌드가 중단됩니다. 누군가 새 사람에게 오래된 CD를 설치할 수있게합니다. 프로젝트 위키에는 설치할 버전에 관한 오래된 지침이 있습니다. 더 나쁜 것은 여전히 ​​문제입니다. 특정 문제를 해결하기 위해 공급 업체와 긴밀히 협력 해야 하고 일주일에 5 개의 라이브러리 세트를 보내면어떤 바이너리 세트가 어떤 행동을 보이는지 추적 할 수 있습니다. 소스 제어 시스템은 해당 문제를 정확하게 해결하는 도구입니다.

여기에 대한 답변 중 일부는 "툴체인을 소스 제어에 두지 마십시오"라고 말합니다. 나는 그것이 틀렸다고 말하지는 않지만 당신이 그것에 대한 견고한 구성 관리 (CM) 시스템이 없다면 툴체인을 소스 제어에 두는 것이 가장 좋습니다 . 다시 한 번 위에서 언급 한 업그레이드 문제를 고려하십시오. 더 나쁘게도, 나는 고용되었을 때 주위에 떠 다니는 4 가지 툴 체인의 풍미가있는 프로젝트를 진행했습니다. 모두 적극적으로 사용합니다 ! 내가 한 첫 번째 작업 중 하나 (빌드를 빌드 한 후)는 툴체인을 소스 제어하에 두었습니다. (견고한 CM 시스템의 아이디어는 희망을 초월했습니다.)

프로젝트마다 다른 툴체인이 필요한 경우 어떻게됩니까? 적절한 사례 : 2 년 후 프로젝트 중 하나가 공급 업체로부터 업그레이드를 받고 모든 Makefile이 중단되었습니다. 그들이 최신 버전의 GNU make에 의존하고 있음이 밝혀졌습니다. 그래서 우리 모두 업그레이드되었습니다. 다른 프로젝트의 Makefile이 모두 고장났습니다. 교훈 : GNU make의 두 버전을 모두 커밋하고 프로젝트 체크 아웃과 함께 제공되는 버전을 실행하십시오.

또는 다른 모든 것을 통제 할 수없는 곳에서 작업하는 경우 "이봐 요, 새 사람이 오늘 시작합니다. 컴파일러 용 CD는 어디에 있습니까?"와 같은 대화가 있습니다. "Dunno, Jack이 종료 한 이후로 그들을 보지 못했다. 그는 CD의 수호자였다." "아, 우리가 2 층에서 이사하기 전에는 아니 었어?" "어쩌면 그들은 상자 또는 무언가에있을 수 있습니다." 이 도구는 3 년이 되었기 때문에 공급 업체로부터 오래된 CD를 얻을 희망은 없습니다.

모든 빌드 스크립트 는 소스 제어에 속합니다. 모두! 환경 변수에 이르기까지. 빌드 머신은 프로젝트 루트에서 단일 스크립트를 실행하여 프로젝트 빌드를 실행할 수 있어야합니다. ( ./build합리적인 표준입니다. ./configure; make거의 비슷합니다.) 스크립트는 필요에 따라 환경을 설정 한 다음 제품을 빌드하는 도구 (make, ant 등)를 실행해야합니다.

그것이 너무 많은 일이라고 생각한다면 그렇지 않습니다. 실제로 많은 작업을 저장합니다. 처음에 파일을 한 번 커밋 한 다음 업그레이드 할 때마다 커밋합니다. 어떤 늑대도 자신의 컴퓨터를 업그레이드하고 최신 버전의 도구에 의존하는 많은 소스 코드를 커밋하여 다른 사람의 빌드를 깨뜨릴 수는 없습니다. 새로운 개발자를 고용 할 때 프로젝트를 확인하고 실행하도록 개발자에게 지시 할 수 있습니다 ./build. 버전 1.8에 많은 성능 조정이 있고 코드, 컴파일러 플래그 및 환경 변수를 조정할 때 새 컴파일러 플래그가 실제로 코드 가 필요 하기 때문에 버전 1.7 패치 빌드에 실수로 적용되지 않도록하려는 경우 그들과 함께 변경 또는 일부 털이 경쟁 조건을 참조하십시오.

무엇보다도 , 언젠가는 엉덩이를 구할 것입니다. 월요일에 제품의 3.0.2 버전을 배송한다고 상상해보십시오. 만세, 축하해 화요일 아침, VIP 고객은 지원 핫라인에 전화를 걸어 18 개월 전에 배송 한 버전 2.2.6의이 긴급하고 긴급한 버그에 대해 불평 합니다. 그리고 여전히 계약 상으로 지원해야하며 버그가 새로운 코드에서 수정되었다는 것을 확인할 수있을 때까지 업그레이드를 거부하고 춤을 출 수있을만큼 큽니다. 두 개의 병렬 유니버스가 있습니다.

• 소스 제어에 라이브러리, 툴체인 및 빌드 스크립트가없고 견고한 CM 시스템이없는 우주에서 ... 올바른 코드 버전을 확인할 수 있지만 빌드하려고 할 때 모든 종류의 오류가 발생합니다. 우리가 5 월에 도구를 업그레이드 했습니까? 아니, 그건 도서관 이었어 좋아, 오래된 도서관으로 돌아 가라-잠깐, 두 가지 업그레이드가 있었습니까? 아 그래, 조금 좋아 보인다. 그러나 이제이 이상한 링커 충돌은 익숙해 보입니다. 이전 라이브러리가 새로운 툴체인에서 작동하지 않았기 때문에 업그레이드해야했습니다. (나머지 노력의 고통을 아끼지 않을 것입니다. 2 주가 걸리며 고객이 아니라 경영진이 아니라 고객이 아닌 그 누구도 행복하지 않습니다.)

• 모든 것이 소스 제어에있는 유니버스에서는 2.2.6 태그를 확인하고 한 시간 내에 디버그 빌드를 준비한 다음 하루 또는 이틀 동안 "VIP 버그"를 다시 작성하고 원인을 추적하여 원인을 수정하십시오. 현재 버전으로 업그레이드하고 고객에게 업그레이드하도록 유도합니다. 스트레스는 있지만 헤어 라인이 3cm 더 높은 다른 우주만큼 나쁘지는 않습니다.

그렇게 말하면 너무 멀리 가져갈 수 있습니다.

• "골드 카피"가있는 표준 OS 설치가 있어야합니다. 아마 README에, 그것을 문서화 입니다 미래 세대가 해당 버전 2.2.6을 알고 이전에만 RHEL 5.3 및 2.3.0에 내장 된 이후에만 우분투 11.04에 내장되도록, 소스 제어에. 이 방법으로 툴체인을 관리하는 것이 더 쉬운 경우, 신뢰할 수있는 시스템인지 확인하십시오.
• 프로젝트 문서는 소스 제어 시스템에서 유지 관리하기가 번거 롭습니다. 프로젝트 문서는 항상 코드 자체보다 우선하며 현재 버전의 코드를 작업하는 동안 다음 버전의 문서를 작성하는 것은 드문 일이 아닙니다. 특히 모든 프로젝트 문서가 이진 문서 인 경우 diff하거나 병합 할 수 없습니다.
• 빌드에 사용 된 모든 버전을 제어하는 ​​시스템이 있다면 그것을 사용하십시오 ! 모든 팀 (빌드 머신 포함)이 동일한 도구 세트에서 끌어 올 수 있도록 전체 팀에서 쉽게 동기화 할 수 있도록하십시오. (데비안의 pbuilder와 같은 시스템을 생각하고 파이썬의 virtualenv를 책임감있게 사용하고 있습니다.)

소스 제어에 포함시키지 않는 유일한 것은 쉽게 재생성하거나 개발자별로 지정할 수있는 파일입니다. 이는 소스 코드로 구성된 실행 파일과 바이너리, 소스 제어 하의 파일 읽기 / 파싱 파일에서 생성 된 설명서 및 IDE 관련 파일을 의미합니다. 다른 모든 것은 버전 관리에 들어가고 적절하게 관리됩니다.

소스 제어의 사용 사례는 다음과 같습니다. 모든 개발자 컴퓨터와 모든 배포 컴퓨터가 유성에 맞으면 어떻게됩니까? 복구가 가능한 한 체크 아웃 및 빌드에 가깝게되기를 원합니다. (이것이 너무 어리석은 경우 "새로운 개발자 고용"과 함께 갈 수 있습니다.)

다시 말해, OS, 앱 및 툴 이외의 모든 것은 VCS에 있어야하고 특정 툴 바이너리 버전에 의존 할 수있는 임베디드 시스템에 있어야합니다. 툴도 VCS에 보관되어 있습니다.

불완전한 소스 제어는 컨설팅 할 때 가장 일반적으로 발생하는 위험 중 하나입니다. 새로운 개발자를 유치하거나 새로운 기계를 설치하는 것과 관련된 모든 종류의 마찰이 있습니다. Continuous Integration 및 Continuous Delivery의 개념과 함께 "Continuous Development"라는 개념을 가져야합니다. IT 담당자는 새로운 개발 또는 배포 시스템을 기본적으로 자동으로 설정하여 개발자가 완료하기 전에 코드를 볼 수 있습니다 그들의 첫번째 커피 잔?

프로젝트에 기여하고 변경 사항을 추적하려는 모든 것.

이진 데이터를 잘 처리하지 않는 scm을 사용하는 경우 이미지와 같은 큰 이진 얼룩이 예외로 포함될 수 있습니다.

Drupal은 git을 사용하므로 git의 용어를 사용합니다. 개별 배포의 구조를 유지하면서 drupal의 공식 저장소에서 모듈 업데이트를 풀다운 할 수 있도록 각 모듈에 대해 하위 리포지토리를 사용합니다. 그렇게하면 소스 제어하에 모든 것을 갖는 이점을 잃지 않으면 서 스크립트 가능성 이점을 얻을 수 있습니다.

다음을 제외한 모든 것이 소스 제어하에 있어야합니다.

• 구성 파일 (개발자 및 / 또는 환경 (개발, 테스트, 프로덕션)마다 다른 구성 옵션이 포함 된 경우)
• 파일 시스템 캐싱을 사용중인 경우 파일 캐시
• 텍스트 파일에 로깅하는 경우 로그 파일
• 캐시 파일 및 로그 파일과 같은 모든 내용이 생성됩니다.
• (매우) 변경되지 않는 큰 이진 파일 (일부 버전 제어 시스템은 좋아하지 않지만 hg 또는 git을 사용하는 경우별로 신경 쓰지 않습니다)

다음과 같이 생각하십시오. 팀의 모든 새 구성원은 구성 항목을 제외한 프로젝트의 작업 사본을 체크 아웃 할 수 있어야합니다.

또한 데이터베이스 스키마 변경 (모든 스키마 변경의 간단한 SQL 덤프)도 버전 제어하에 두어야합니다. 프로젝트에 적합한 사용자 및 API 문서를 포함시킬 수 있습니다.

@maple_shaft는 주석의 환경 구성 파일에 관한 첫 번째 진술에서 중요한 문제를 제기합니다. Drupal 또는 일반 CMS 프로젝트에 관한 질문의 구체적 내용에 대한 답변입니다. 이러한 시나리오에는 일반적으로 로컬 및 프로덕션 데이터베이스가 있으며 하나의 환경 구성 옵션은 이러한 데이터베이스의 신임 정보 (및 유사한 신임 정보)입니다. 여러 가지 보안 문제가 발생할 수 있으므로 소스 제어하에 있지 않은 것이 좋습니다.

그러나보다 일반적인 개발 워크 플로에서는 메이저 _ 샤프트에 동의하여 환경 구성 옵션이 모든 환경의 1 단계 빌드 및 배포를 위해 소스 제어하에 있어야한다는 데 동의합니다.

자동화 된 빌드가 생성하는 것은 소스 제어에 포함 되지 않습니다 . 빌드 중에 수정 이 필요 없는 것은 소스 제어에 포함됩니다. 그렇게 간단합니다.

예를 들어 다음은 소스 제어에 포함되지 않습니다.

• 생성 된 코드
• 생성 된 바이너리
• 빌드로 생성 된 것
• 서비스, ​​프로세스, 웹 애플리케이션에 의해 런타임에 생성 된 모든 것

소스 제어에는 어떤 것이 있습니까?

• 인간이 만드는 모든 것
• 다른 사람이나 그룹 (예 : 소스 제어가 배포되는 타사 사내 라이브러리 또는 오픈 소스 프로젝트의 바이너리)에 의해 생성 된 모든 것.
• 데이터베이스와 같은 것을 생성하는 스크립트 및 기타 소스 (즉, 모든 DBA가 AWOL로 이동하는 경우 어떻게 DB를 다시 생성 할 것인가)

이러한 규칙은 소스 제어에 있는 모든 것이 사람에 의해 수정 될 수 있으며 누군가가 가치있는 이유를 이해하는 데 소중한 시간이 걸릴 수 있다는 개념을 전제로합니다 .

작업해야하고 변경할 수있는 모든 것은 어떤 방식 으로든 버전 화해야합니다. 그러나 두 개의 독립적 인 시스템이이를 추적 할 필요는 거의 없습니다.

안정적인 방식으로 생성 된 것은 일반적으로 소스 버전에 첨부 할 수 있으므로 생성 된 소스, 시스템에서 다른 시스템으로 전달되지 않은 바이너리 등 독립적으로 추적 할 필요가 없습니다.

아마 아무도 신경 쓰지 않는 빌드 로그와 다른 것들 (그러나 당신은 결코 알지 못합니다)은 일반적으로 그것을 생성하는 사람 : jenkins 등이 가장 잘 추적합니다.

한 시스템에서 다른 시스템으로 전달되는 제품을 추적해야하지만 Maven 저장소는이를 수행하는 좋은 방법입니다. 소스 제어가 제공하는 제어 수준이 필요하지 않습니다. 산출물은 종종 같은 범주에 속합니다.

남아있는 것은 무엇이든 (이 시점에서 소스 파일과 빌드 서버 구성보다 많지 않아야 함) 소스 제어에 들어갑니다.

내 대답은 매우 간단합니다. 바이너리가 아닙니다. 암시 적으로 거의 모든 것.

(그러나 데이터베이스 백업이나 스키마 마이그레이션 또는 사용자 데이터는 아닙니다.)

소스 제어는 변경 내용 추적 메커니즘입니다. 누가 무엇을 언제 변경했는지 알고 싶을 때 사용하십시오.

소스 컨트롤은 무료가 아닙니다. 워크 플로우에 복잡성을 추가하고 새로운 동료를위한 교육이 필요합니다. 비용 대비 이점을 측정하십시오.

예를 들어 데이터베이스를 제어하기가 어려울 수 있습니다. 예전에는 텍스트 파일에 정의를 수동으로 저장 한 다음 소스 제어에 추가해야하는 시스템이있었습니다. 시간이 많이 걸리고 신뢰할 수 없었습니다. 신뢰할 수 없으므로 새 데이터베이스를 설정하거나 변경 시간을 확인하는 데 사용할 수 없습니다. 그러나 우리 관리자는 "모든 것이 소스 제어에 있어야한다"고 생각했기 때문에 수많은 시간을 낭비했습니다.

소스 컨트롤은 마법이 아닙니다. 시도해보십시오. 그러나 비용을 상쇄하기에 충분한 가치가 없다면 포기하십시오.

소스 제어에 넣지 않은 것 :

• 비밀 키 및 비밀번호
• SDK는 동일한 디렉토리이지만 SDK에 패치를 적용하면 앱이 아닌 프레임 워크이므로 다른 프로젝트로 만들어야합니다.
• 와 같은 타사 라이브러리 마이그레이션, 백업, 컴파일 된 코드, 다른 라이센스 하의 코드 (아마도)에서 남은 음식

따라서 hg addremoveSDK가 업데이트 될 때마다 새로운 클론이 만들어지기 때문에 예를 들어 하지 않습니다 . 또한 SDk가 업데이트 될 때마다 전체 백업을 수행하고 리포지토리에서 복제 된 새 버전이 올바른지 확인합니다.

우려 사항을 다루는 다음 책을 적극 권장합니다.

지속적인 제공 : 빌드, 테스트 및 배포 자동화를 통한 안정적인 소프트웨어 릴리스 . 특히, 2 장에서는 소스 제어에 배치 할 항목에 대해 설명합니다. 대부분의 사람들이 말했듯이 빌드의 결과로 생성 된 콘텐츠를 제외한 모든 것이 실제로 있습니다.

@FrustratedWithFormsDesigner가 제공하는 대답 중 하나에 동의하지 않습니다 . 프로젝트를 빌드하는 데 필요한 도구를 버전 제어에 두지 않는 것을 옹호하기 때문입니다. 소스 제어의 어느 곳에 (빌드중인 코드와 인접한) 프로젝트를 빌드하기위한 빌드 스크립트와 명령 행에서만 실행되는 스크립트를 빌드해야합니다. 도구로 IDE와 편집기를 의미한다면 프로젝트를 빌드 할 필요가 없습니다. 이들은 개발자를위한 능동 / 빠른 개발에 적합하며 이러한 유형의 환경 설정은 스크립트로 작성하거나 SCM의 다른 섹션 또는 일부 유형의 이진 관리 서버에서 다운로드 할 수 있으며 이러한 IDE 설정은 가능한 한 자동화되어야합니다.

또한 소스 제어에 환경 구성을 배치하는 것에 대한 @Yannis Rizos의 의견에 동의하지 않습니다 . 그 이유는 스크립트 만 사용하여 환경을 자유롭게 재구성 할 수 있어야하고 소스 제어에서 구성 설정이 없으면 관리 할 수 ​​없기 때문입니다. 또한이 정보를 소스 제어에 두지 않고 다양한 환경에 대한 구성이 어떻게 발전했는지에 대한 기록도 없습니다. 이제 프로덕션 환경 설정이 기밀로 유지되거나 회사에서이를 버전 관리에 배치하고 싶지 않을 수 있으므로 두 번째 옵션은 여전히 ​​히스토리를 갖도록 버전 관리에 설정하고이 저장소에 액세스를 제한하는 것입니다.

모든 코드를 버전 관리 상태로 유지하고 모든 구성 및 사용자 데이터를 차단하십시오. 드루팔에 특화하려면 파일과 설정을 제외한 모든 것을 버전 관리에 넣어야합니다.