생성 된 코드를 소스 제어에 저장해야합니까?

이것은 제가 참여하고있는 토론입니다. 더 많은 의견과 관점을 얻고 싶습니다.

DB 작업을 처리하기 위해 빌드 시간에 생성되는 클래스가 있습니다 (이 특정 경우에는 SubSonic을 사용하지만 질문에 대해 매우 중요하다고 생각하지 않습니다). 생성은 Visual Studio에서 사전 빌드 단계로 설정됩니다. 따라서 개발자 (또는 공식 빌드 프로세스)가 빌드를 실행할 때마다 이러한 클래스가 생성 된 다음 프로젝트로 컴파일됩니다.

이제 일부 사람들은 이러한 클래스를 소스 제어에 저장하면 코드가 자신의 환경에서 생성 된 것과 일치하지 않을 경우 혼란을 일으킬 수 있다고 주장합니다.

일반적으로 블랙 박스로 취급 되더라도 코드의 역사를 추적 할 수있는 방법을 갖고 싶습니다.

어떤 주장이나 반대 주장?

위에서 언급 한 이유 때문에이 시점에서 수락 된 답변을 선택하지 않겠습니다.

소스 제어에 저장하는 것은 가치가있는 것보다 더 많은 문제입니다.

어떤 가치가 되려면 빌드를 할 때마다 커밋을해야합니다.

일반적으로 우리는 생성 된 코드 (idl, jaxb 등)를 내가 작업하는 소스 제어 외부에 두며 문제가되지 않았습니다.

소스 코드 제어에 넣으십시오. 미래의 개발자가 작성한 모든 기록을 사용할 수 있다는 장점은 동기화 후 가끔 재 구축하는 사소한 고통보다 큽니다.

내 개인 저장소의 소스 트리에 대한 변경 사항을 표시하고 싶을 때마다 모든 '생성 된 파일'이 변경된 것으로 표시되고 커밋이 필요합니다.

자동 생성 된 변경 사항이 아닌 수행 된 실제 업데이트 만 포함하는보다 깔끔한 수정 목록을 갖고 싶습니다.

그대로두고 빌드 후에 생성 된 각 파일에 '무시'를 추가합니다.

이런 식으로보세요 : 개체 파일을 소스 제어로 확인합니까? 생성 된 소스 파일은 개체 파일, 라이브러리 및 실행 파일과 같은 빌드 아티팩트입니다. 동일하게 취급되어야합니다. 대부분은 생성 된 개체 파일과 실행 파일을 소스 제어로 검사해서는 안된다고 주장합니다. 생성 된 소스에 동일한 인수가 적용됩니다.

생성 된 파일의 기록 버전을 확인해야하는 경우 해당 소스의 기록 버전과 동기화하고 다시 빌드 할 수 있습니다.

모든 종류의 생성 된 파일을 소스 제어로 확인하는 것은 데이터베이스 비정규 화와 유사합니다. 있습니다 가끔 (일반적으로 성능)이 작업을 수행하는 이유는, 그러나 데이터가 비정규되면 정확성과 일관성을 유지하기 위해 더 힘들어 질수록이 큰 관심 만 수행해야합니다.

생성 된 코드 (또는 다른 아티팩트)를 소스 제어에 추가하지 말아야합니다. 생성 된 코드가 주어진 입력에 대해 동일하면 비교하려는 버전을 확인하고 비교할 코드를 생성 할 수 있습니다.

나는 DRY 원칙이라고 부릅니다. 빌드시 이러한 코드 파일을 생성하는 데 사용되는 "소스 파일"이 저장소에 이미있는 경우 동일한 코드를 "두 번"커밋 할 필요가 없습니다.

또한 언젠가 코드 생성이 중단되는 경우 이러한 방식으로 일부 문제를 방지 할 수 있습니다.

아니요, 세 가지 이유가 있습니다.

1. 소스 코드는 현재 또는 이전 시점을 기준으로 애플리케이션의 스냅 샷을 재현하는 데 필요하고 충분합니다. 그 이상도 이하도 아닙니다. 이것이 의미하는 것은 누군가가 체크인 한 모든 것에 대한 책임이 있다는 것입니다. 일반적으로 저는 제가 작성한 코드에 대해 책임을지는 것이 기쁩니다. 그러나 제가 작성한 코드의 결과로 생성 된 코드는 아닙니다.

2. 나는 누군가가 현재 일 수도 있고 아닐 수도있는 중간 코드를 사용하여 기본 소스에서 빌드를 바로 가기하려고하는 유혹을 받고 싶지 않습니다 (더 중요한 것은 제가 책임을 받아들이고 싶지 않다는 것입니다.). 일부 사람들은 부분 빌드를 기반으로하는 중간 코드에서 충돌을 디버깅하는 데 의미없는 프로세스에 휩싸 이도록 유혹합니다.

3. 일단 소스 제어에 들어가면 a. 거기있는 것, b. 그것은 현재이고 c. 다른 모든 것과 안정적으로 통합 할 수 있습니다. 여기에는 더 이상 사용하지 않을 때 제거하는 것도 포함됩니다. 그 책임이 적을수록 좋습니다.

나는 정말로 당신이 그들을 체크인해야한다고 생각하지 않습니다.

확실히 생성 된 코드의 모든 변경은 소음이 될 것입니다 (환경 간 변경) 또는 다른 결과 (예 : DB 변경)의 결과로 변경됩니다. DB의 생성 스크립트 (또는 기타 종속성)가 소스 제어에있는 경우 생성 된 스크립트도 왜 필요합니까?

일반적인 규칙은 아니오입니다. .하지만 코드 생성에 시간이 걸리는 경우 (DB 액세스, 웹 서비스 등으로 인해) 소스 제어에 캐시 된 버전을 저장하고 모든 사람의 고통을 덜어주고 싶을 수 있습니다.

도구는 또한이를 인식하고 필요할 때 소스 제어에서 체크 아웃을 처리해야합니다. 너무 많은 도구가 이유없이 소스 제어에서 체크 아웃하기로 결정합니다.
좋은 도구는 캐시 된 버전을 건드리지 않고 (파일의 시간 단계를 수정하지 않고) 사용합니다.

또한 파일을 수정하지 않도록 생성 된 코드 내부에 큰 경고를 넣어야합니다. 맨 위에있는 경고로는 충분하지 않으며 12 줄마다 반복해야합니다.

생성 된 DB 코드도 저장하지 않습니다. 생성 된 DB 코드는 소스 파일에서 특정 버전으로 자유롭게 가져올 수 있습니다. 그것을 저장하는 것은 바이트 코드 등을 저장하는 것과 같습니다.

이제 주어진 버전에서 사용되는 코드 생성기를 사용할 수 있는지 확인해야합니다! 최신 버전은 다른 코드를 생성 할 수 있습니다.

놔둬.

생성 된 파일을 체크인하는 경우 뭔가 잘못된 것입니다. 잘못이 다를 수 있습니다 무엇, 그것은 당신의 빌드 프로세스는 다른 비효율적이다, 또는 무언가 일 수 있었다,하지만 난 그것을 볼 수 없습니다 적 좋은 생각 는 . 기록은 생성 된 파일이 아니라 소스 파일과 연결되어야합니다.

차이점을 해결하고 빌드에 의해 더 이상 생성되지 않는 파일을 찾은 다음 삭제하는 등의 시도를하는 사람들에게 골칫거리 일뿐입니다.

생성 된 파일을 체크인하는 사람들은 고통의 세계가 기다리고 있습니다!

생성 된 파일을 체크인하려는 특별한 경우가 있습니다. 다른 파일을 생성하는 데 사용 된 도구를 사용할 수없는 시스템에서 빌드해야 할 수 있습니다. 이것의 전형적인 예이자 제가 함께 일하는 것은 Lex와 Yacc 코드입니다. 다양한 플랫폼과 아키텍처에서 빌드하고 실행해야하는 런타임 시스템을 개발하기 때문에 인터페이스 정의를위한 렉싱 / 파싱 코드를 생성하는 데 필요한 도구가 아닌 C 및 C ++ 컴파일러가있는 대상 시스템에만 의존 할 수 있습니다. 역자. 따라서 문법을 변경할 때 생성 된 코드를 확인하여 구문 분석합니다.

조금 늦게 도착 ... 어쨌든 ...

컴파일러의 중간 파일을 소스 버전 제어에 넣겠습니까? 코드 생성의 경우 정의에 따라 소스 코드는 생성기의 입력이며 생성 된 코드는 "실제"소스와 빌드 된 애플리케이션 간의 중간 파일로 간주 될 수 있습니다.

그래서 저는 다음과 같이 말할 것입니다 : 생성 된 코드를 버전 제어 아래에 두지 말고 생성기와 입력을 두십시오.

구체적으로 필자는 작성한 코드 생성기로 작업합니다. 생성 된 소스 코드를 버전 제어하에 유지할 필요가 없었습니다. 생성기가 특정 성숙도 수준에 도달했기 때문에 입력 (예 : 모델 설명)이 변경되었지만 생성 된 코드의 내용을 관찰 할 필요가 없었습니다.

일부 프로젝트에서는 생성 된 코드를 소스 제어에 추가하지만 실제로는 다릅니다. 내 기본 지침은 생성 된 코드가 컴파일러의 내장 부분이면 추가하지 않을 것입니다. 생성 된 코드가이 경우 SubSonic과 같은 외부 도구에서 가져온 경우 소스 제어에 if를 추가합니다. 주기적으로 구성 요소를 업그레이드하는 경우 버그 또는 문제가 발생할 경우 생성 된 소스의 변경 사항을 알고 싶습니다.

생성 된 코드를 체크인해야하는 한 최악의 시나리오는 파일을 수동으로 구분하고 필요한 경우 파일을 되 돌리는 것입니다. svn을 사용하는 경우 svn에 사전 커밋 후크를 추가하여 파일이 실제로 변경되지 않은 경우 커밋을 거부 할 수 있습니다.

구성 관리 작업 (버전 제어는 한 부분에 불과 함)은 다음을 수행 할 수 있습니다.

• 제공되는 모든 빌드에 어떤 변경 사항과 버그 수정이 적용되었는지 확인하십시오.
• 원본 소스 코드에서 시작하여 제공된 빌드를 정확히 재현 할 수 있습니다. 자동 생성 된 코드는 언어에 관계없이 "소스 코드"로 간주되지 않습니다.

첫 번째는 클라이언트 또는 최종 사용자에게 "지난 주에보고 한 버그가 수정되었으며 새로운 기능이 추가되었습니다"라고 말할 때 2 시간 후에 다시 돌아와 "아니요"라고 말하지 않도록합니다. 또한 그들은 "왜 X를하고 있는가? 우리는 X를 요구 한 적이 없다"라고 말하지 않는다.

두 번째는 클라이언트 또는 최종 사용자가 1 년 전에 발행 한 일부 버전에서 버그를보고 할 때 해당 버전으로 돌아가서 버그를 재현하고 수정하고 수정이 버그를 제거했다는 것을 증명할 수 있음을 의미합니다. 컴파일러 및 기타 수정 사항의 일부 섭동.

즉, 컴파일러, 라이브러리 등도 CM의 일부가되어야합니다.

이제 질문에 답하기 위해 : 위의 모든 작업을 수행 할 수 있다면 중간 표현을 기록 할 필요가 없습니다. 어쨌든 동일한 답을 얻을 수 있기 때문입니다. 위의 모든 것을 할 수 없다면, 같은 일을 두 번하고 같은 답을 얻을 수 있다는 것을 보장 할 수 없기 때문에 모든 베팅이 해제됩니다. 따라서 모든 .o 파일을 버전 제어하에 둘 수도 있습니다.

정말 다릅니다. 궁극적으로 목표는 필요한 경우 가지고 있던 것을 재현 할 수있는 것입니다. 바이너리를 정확하게 재생성 할 수 있다면 저장할 필요가 없습니다. 그러나 당신은 당신의 물건을 다시 만들려면 아마도 당신이 처음에했던 정확한 구성이 필요할 것임을 기억할 필요가 있습니다. 그것은 당신의 소스 코드뿐만 아니라 당신의 빌드 환경, IDE, 심지어 다른 라이브러리를 의미 할 수도 있습니다. , 생성기 또는 물건, 사용했던 정확한 구성 (버전)으로.

빌드 환경을 새로운 버전으로 업그레이드했거나 심지어 다른 공급 업체로 업그레이드했을 때 프로젝트에서 문제가 발생했습니다. 이전에 가지고 있던 정확한 바이너리를 다시 만들 수 없었습니다. 배포 할 바이너리가 특히 보안 환경에서 일종의 해시에 의존하고 컴파일러 업그레이드 등으로 인해 재생성 된 파일이 어떻게 든 다를 때 이것은 진정한 고통입니다.

따라서 생성 된 코드를 저장 하시겠습니까? 아니요. 릴리스 된 바이너리 또는 결과물 (저장할 때 함께 재현 한 도구 포함). 그런 다음 소스 제어에 저장할 필요가 없으며 해당 파일을 잘 백업하십시오.

정답은 "따르다"입니다. 그것은 고객의 요구가 무엇인지에 달려 있습니다. 코드를 특정 릴리스로 롤백하고 코드없이 외부 감사에 맞설 수 있다면 여전히 확고한 기반에 있지 않습니다. 개발자로서 우리는 '노이즈', 고통 및 디스크 공간뿐만 아니라 지적 재산을 생성하는 역할을 맡고 있으며 법적 결과가있을 수 있다는 사실을 고려해야합니다. 2 년 전에 고객이 본 것과 똑같은 방식으로 웹 사이트를 재생성 할 수 있다는 것을 판사에게 증명할 수 있습니까?

저는 Gen'd 파일을 저장하거나 저장하지 말라고 제안하는 것이 아닙니다. 어떤 방식 으로든 주제 전문가와 관련이 없는지 여부를 결정하는 방식이 틀렸을 것입니다.

내 2 센트.

여기에 제시된 찬성 및 반대 의견이 모두 있습니다. 기록을 위해 Visual Studio에서 T4 생성 시스템을 빌드하고 기본 제공 옵션으로 인해 생성 된 코드가 체크인됩니다. 체크인하지 않으려면 조금 더 열심히 작업해야합니다.

나에게 중요한 고려 사항은 입력 또는 생성기 자체가 업데이트 될 때 생성 된 출력을 비교하는 것입니다.

출력을 체크인하지 않은 경우 생성기를 업그레이드하거나 입력을 수정하기 전에 생성 된 모든 코드의 복사본을 가져와야 새 버전의 출력과 비교할 수 있습니다. 나는 이것이 상당히 지루한 프로세스라고 생각하지만 출력을 체크인하면 새 출력을 저장소와 비교하는 간단한 문제입니다.

이 시점에서 "왜 생성 된 코드의 변경 사항에 관심이 있습니까?"라고 묻는 것이 합리적입니다. (특히 객체 코드와 비교할 때) 저는 몇 가지 중요한 이유가 있다고 생각합니다. 그 이유는 고유 한 문제 라기보다는 현재의 예술 상태에 있습니다.

1. 생성 된 코드와 밀접하게 결합되는 수기 코드를 작성합니다. 요즘에는 obj 파일의 경우 전체적으로 그렇지 않습니다. 생성 된 코드가 변경되면 슬프게도 일부 손으로 쓴 코드가 일치하도록 변경해야하는 경우가 많습니다. 사람들은 종종 생성 된 코드에서 확장 성 지점과의 높은 수준의 하위 호환성을 관찰하지 않습니다.

2. 생성 된 코드는 단순히 동작을 변경합니다. 컴파일러에서는 이것을 용납하지 않을 것이지만 공정하게 응용 프로그램 수준 코드 생성기는 더 넓은 범위의 허용 가능한 솔루션으로 다른 문제 분야를 목표로 삼고 있습니다. 이전 행동에 대한 가정이 이제 깨 졌는지 확인하는 것이 중요합니다.

3. 릴리스마다 생성기의 출력을 100 % 신뢰하지는 않습니다. 컴파일러 공급 업체의 엄격함으로 빌드 및 유지 관리되지 않더라도 생성기 도구에서 얻을 수있는 많은 가치가 있습니다. 릴리스 1.0은 애플리케이션에 대해 완벽하게 안정적 일 수 있지만 1.1에는 현재 사용 사례에 몇 가지 결함이있을 수 있습니다. 또는 입력 값을 변경하고 이전에 사용하지 않은 생성기의 새로운 부분을 사용하고 있음을 알게됩니다. 잠재적으로 결과에 놀라게됩니다.

본질적으로 이러한 모든 것들은 도구 성숙도에 도달합니다. 대부분의 비즈니스 앱 코드 생성기는 컴파일러 또는 심지어 lex / yacc 수준 도구가 수년 동안 있었던 수준에 가깝지 않습니다.

양측 모두 타당하고 합리적인 주장을 가지고 있으며 공통점에 동의하기가 어렵습니다. VCS (버전 제어 시스템)는 개발자가 입력 한 파일을 추적하고 VCS 내부의 파일은 개발자가 수작업으로 제작했으며 개발자는 파일 수정 내역과 변경 사항에 관심이 있다고 가정합니다. 이 가정은 "체크 아웃 할 때이 파일을 얻고 싶습니다."라는 두 개념을 동일하게합니다. 및 "이 파일의 변경에 관심이 있습니다."

이제 양측의 주장은 다음과 같이 바꿀 수 있습니다.

• "이 컴퓨터에 파일을 생성 할 도구가 없기 때문에 체크 아웃 할 때 생성 된 모든 파일을 가져오고 싶습니다."
• "이 파일의 변경에 관심이 없으므로 VCS에 넣지 말아야합니다."

다행히도 두 가지 요구 사항이 근본적으로 충돌하지 않는 것 같습니다. 현재 VCS를 일부 확장하면 둘 다 가질 수 있습니다. 즉, 잘못된 딜레마입니다. 잠시 생각해 보면 문제가 VCS의 가정에서 비롯된다는 사실을 깨닫는 것이 어렵지 않습니다. VCS는 개발자가 손으로 만든 파일과 개발자가 손으로 만든 파일이 아닌 파일을 구별해야하지만이 VCS 안에있을뿐입니다. 일반적으로 소스 파일 (코드)이라고 부르는 첫 번째 파일 범주의 경우 VCS가 이제 훌륭한 작업을 수행했습니다. 후자의 경우 VCS는 내가 아는 한 아직 그러한 개념을 가지고 있지 않았습니다.

요약

내가 의미하는 바를 설명하기 위해 git을 예로 들겠습니다.

• git status 기본적으로 생성 된 파일을 표시하지 않아야합니다.
• git commit 생성 된 파일을 스냅 샷으로 포함해야합니다.
• git diff 기본적으로 생성 된 파일을 표시하지 않아야합니다.

추신

Git 후크를 해결 방법으로 사용할 수 있지만 git가 기본적으로 지원한다면 좋을 것입니다. gitignore무시 된 파일은 VCS로 이동하지 않으므로 요구 사항을 충족하지 않습니다.enter code here

나는 주장 할 것이다. 코드를 확인하고, 빌드 번호를 수정하고, 소프트웨어를 빌드 한 다음 테스트하는 지속적인 통합 프로세스를 사용하는 경우 해당 코드를 저장소의 일부로 사용하는 것이 더 간단하고 쉽습니다.

또한 소프트웨어 저장소에서 가져 오는 모든 "스냅 샷"의 일부이자 소포입니다. 소프트웨어의 일부인 경우 저장소의 일부 여야합니다.

예, 소스 제어하에두고 싶습니다. 구성 관리 관점에서 소프트웨어 빌드를 생성하는 데 사용되는 모든 것이 다시 생성 될 수 있도록 제어되어야합니다. 생성 된 코드는 쉽게 다시 만들 수 있지만 두 빌드간에 날짜 / 타임 스탬프가 다르기 때문에 동일하지 않다는 주장을 할 수 있습니다. 정부와 같은 일부 영역에서는 이것이 수행되는 작업을 많이 요구합니다.

일반적으로 생성 된 코드는 해당 코드를 생성 한 코드의 수정 이력으로 추적 할 수 있으므로 소스 제어에 저장할 필요가 없습니다!

그러나 OP가 생성 된 코드를 수동으로 작성하는 대신 응용 프로그램의 데이터 액세스 계층으로 사용하는 것으로 들립니다. 이 경우 빌드 프로세스를 변경하고 런타임 코드의 중요한 구성 요소이므로 코드를 소스 제어에 커밋합니다. 또한 개발자가 다른 분기에 대해 다른 버전의 도구를 사용해야하는 경우 빌드 프로세스에서 코드 생성 도구에 대한 종속성을 제거합니다.

코드는 모든 빌드가 아니라 한 번만 생성하면되는 것 같습니다. 개발자가 개체가 데이터베이스에 액세스하는 방식을 추가 / 제거 / 변경해야하는 경우 수동으로 수정하는 것처럼 코드를 다시 생성해야합니다. 이를 통해 빌드 프로세스의 속도가 빨라지고 데이터 액세스 계층에 대한 수동 최적화가 가능하며 데이터 액세스 계층의 기록이 간단한 방식으로 유지됩니다.

나는 (유감스럽게도) 적절한 빌드 환경을 설정하는 데 신경을 쓸 수 없거나 설정하는 기술이없는 사람들과 원격으로 작업하기 때문에 소스 제어 아래에 많은 파생 소스를 배치하게됩니다. 파생 된 소스는 정확하게 구축됩니다. (그리고 Gnu autotools에 관해서는 저도 그런 사람들 중 하나입니다. 각각 다른 버전의 autotools와 함께 작동하는 세 가지 다른 시스템으로 작업 할 수는 없습니다.

이러한 종류의 어려움은 비용을 지불하는 사람이 균일 한 빌드 환경을 고집 할 수있는 유료 프로젝트보다 파트 타임, 자원 봉사, 오픈 소스 프로젝트에 더 많이 적용됩니다.

이렇게하면 기본적으로 파생 파일을 한 사이트에서만 빌드하거나 제대로 구성된 사이트에서만 빌드하는 것입니다. Makefile (또는 기타)은 실행중인 위치를 알 수 있도록 설정해야하며 안전한 빌드 사이트에서 실행되고 있다는 것을 알지 못하는 경우 소스 재 파생을 거부해야합니다.

소스 코드의 일부인 경우 생성자 또는 생성 대상에 관계없이 소스 제어에 넣어야합니다. 소스 제어가 시스템을 재생성하지 않고도 시스템의 현재 상태를 반영하기를 원합니다.

여러 가지 이유로 생성 된 코드를 소스 제어에 포함합니다. 많은 사람들이 이미 말한 것을 반복하고 있지만, 몇 가지 이유는

1. 소스 제어의 코드 파일을 사용하면 Visual Studio 사전 빌드 단계를 사용하지 않고도 코드를 컴파일 할 수 있습니다.
2. 두 버전을 전체적으로 비교할 때 생성 된 코드가 수동으로 확인하지 않고도 두 태그간에 변경되었는지 아는 것이 좋습니다.
3. 코드 생성기 자체가 변경되는 경우 생성 된 코드의 변경 사항이 적절하게 변경되는지 확인해야합니다. 즉, 생성기가 변경되었지만 출력이 변경되어서는 안되는 경우 코드를 커밋 할 때 이전에 생성 된 것과 지금 생성 된 코드에 차이가 없습니다.

내가 생성 된 파일을 떠날 에서 소스 트리의, 그러나 그것을 넣어 에서 별도의 빌드 트리.

예 : 워크 플로우는

1. 일반적으로 소스 체크인 / 아웃 / 수정 / 병합 (생성 된 파일 없음)
2. 적절한 경우 소스 트리를 깨끗한 빌드 트리로 확인하십시오.
3. 빌드 후 감사 / 규제 목적으로 존재해야하는 모든 "중요"파일 ( "실제"소스 파일, 실행 파일 + 생성 된 소스 파일)을 체크인하십시오. 이를 통해 릴리스 / 테스트 스냅 샷 등과 관련되고 일상적인 개발에서 분리 된 시간 증분에서 적절한 생성 된 모든 코드 + 실행 파일 + 무엇이든 기록을 제공합니다.

Subversion / Mercurial / Git / etc에서 두 위치에서 실제 소스 파일의 기록을 함께 묶는 좋은 방법이있을 것입니다.

양측에 매우 강력하고 설득력있는 의견이있는 것 같습니다. 가장 많이 득표 한 답변을 모두 읽고 특정 사례에 적용되는 주장을 결정하는 것이 좋습니다.

업데이트 : 나는 결정적인 대답이 하나 있다고 정말로 믿었 기 때문에이 질문을했습니다. 모든 답변을 살펴보면 그런 답변은 없다고 확신 할 수 있습니다. 결정은 둘 이상의 매개 변수를 기반으로해야합니다. 다른 답변을 읽으면이 문제를 결정할 때 스스로에게 물어봐야 할 질문 유형에 대한 매우 좋은 지침이 될 수 있습니다.