프로덕션 코드 전용 Subversion / source control?

나는 1 년 전에 컴퓨터 과학 대학을 졸업했으며, 현재 소규모 웹 개발 회사 (나와 다른 개발자, 관리자, 고객 서비스 및 테스터)에서 근무하고 있습니다. 시작하기 직전까지는 소스 제어 시스템이 없었습니다. 우리는 이제 SVN 구현을 서서히 시작하고 있지만 다른 (상위) 개발자 (이후 Joe라고도 함)는 SVN 저장소에 커밋해야하는 유일한 코드는 프로덕션 용으로 테스트 및 승인 된 코드 뿐이라고 주장합니다. 즉, 대규모 프로젝트에서는 한 번에 몇 주 동안 커밋이 없을 수 있습니다.

이것이 정상적인 습관입니까? 다음을 포함하여 소스 제어의 많은 이점을 잃는 것처럼 보입니다.

• 프로젝트 진행 상황을 세밀하게 추적
• 문제가 표시되고 해결 될 때 추적
• 실수를 쉽게 롤백
• 손쉬운 코드 백업으로 워크 스테이션이 다운 되더라도 크게 손실되지
• 여기에 설명 된대로 수정본을 실행 파일로 스탬핑한다고 가정하면 어떤 프로덕션 사이트에서 어떤 코드가 실행 중인지 정확하게 식별
• 손쉬운 협업 (우리는 팀워크를 수행하지는 않지만 모든 솔로 프로젝트 임)
• 기타.

편집 : 나는 역사적 으로이 회사에서 진정한 팀워크가 없었 음을 강조해야합니다. 별도의 프로젝트를 수행하는 개발자는 두 명뿐입니다. 또한 많은 프로젝트가 작기 때문에 몇 주 안에 완료 될 수 있습니다. 그리고이 회사는 10 년 이상 사업을 해왔으며 소스 제어 없이도 잘 지 냈습니다. 프로젝트는 일반적으로 예상 기간 내에 완료됩니다.

예상 시간 내에 프로젝트가 완료되면 고객이 행복한 고객이라고 가정하는 것이 안전합니까? :)

회사는 새로운 유형의 프로젝트를 시작하고 점점 커지는 고통이나 "이동하는 고통"을 겪고있는 것 같습니다. 여기에 계속 가정 많이 ... 나와 함께 견딜!

코드의 구성 및 제어가 귀하와 귀하의 팀을 내부적으로 도울 수 있다고 확신하는 경우 SVN을 고려해야합니다 (IMHO). 이 경로로 이동하면 실제로 보너스 포인트를 얻을 수 있으며 회사는 더 높은 품질의 제품을 만들 수 있으므로 더 행복한 고객을 만들 수 있습니다!

경영진과의 투쟁이 긴장된 근무 환경을 조성 할 것 같으면 조심하십시오. 사실은 소유자가 회사를 만들었습니다. 뿐만 아니라 그들은 성공적인 회사를 만들었습니다. 도박에 능숙하기 때문에 잭팟에 부딪 힐 가능성은 거의 없습니다.

존중하고 말을들을 수 있습니다.

이것이 결국보다 효율적이고 행복한 팀이 될 수 있기를 바랍니다. 내 경험상, 그것은 좌절 된 관리로 얻기가 어렵습니다.

조는 거의 죽었다. 이제 검증 된 프로덕션 준비된 코드를 나타내는 하나의 "깨끗한"분기가 있다는 주장을 할 수 있습니다. 그러나 준비가 완료 될 때까지 소스 제어를 사용하지 않는 것은 솔직히 자멸 적입니다. 진없이 마티니를 만들려고하는 것과 같습니다.

"노인"은 실제로 매우 미숙합니다. 컴파일 할 수있는 코드 (있는 경우 테스트를 통과 한 코드)는 소스 제어에 전념해야합니다. 소스 제어는 코드를 공유하고 SW를 점진적으로 구축하기위한 핵심 자산입니다.

좋은 점은 생산 코드 (마지막 안정 버전)를 분리하는 것이지만 그러한 경우 소스 제어 시스템에는 태그 / 라벨 및 분기와 같은 기능이 포함됩니다.

누군가 2 ~ 3 일 안에 아무것도하지 않으면 우리 팀은 매우 의심스러워합니다. 그것은 그가 몇 가지 문제를 가지고 있고 아마도 도움이 필요하다는 것을 의미합니다. 소스 제어의 또 다른 지점은 일반적으로 정기적으로 백업되므로 개발 시스템에는 해당되지 않습니다. 디스크가 충돌하면 몇 주 동안 작업이 손실됩니다.

Joe가 옳고 그른지 (그가 틀렸는 지)에 대한 질문을 제쳐두고, Git 또는 Mercurial 과 같은 분산 버전 제어 시스템을 사용하면 타협에 도달 할 수있는 것 같습니다 .

이렇게하면 자신과 다른 개발자가 로컬 리포지토리에서 작업하여 소스 컨트롤에 대한 변경 내용을 조기에 자주 커밋하지만 "테스트 준비 및 프로덕션 준비 완료"가 될 때까지 "프로덕션"리포지토리로 변경 내용을 푸시하지 않습니다. 당신은 몇 주 동안 일한 모든 것들에 대한 완전한 역사를 가지고있을 것이며, Joe는 생산 준비가되어 축복받은 변화의 역사를 가진 원시 저장소를 가질 것입니다.

당신이 나열한 바로 그 이유는 이해가되지 않습니다. 버전 제어를 사용하는 이점없이 버전 제어를 사용하는 것과 같습니다.

Joe는 소스 제어 시스템이 소스 코드 프로덕션 릴리스의 백업을 영화 롭게하는 것이 아니라 미래의 자기 자신과 동료를 위해 코드 진행 단계와 성숙 단계에 대해 말함으로써 프로그래머에게 유용한 도구라는 것을 이해하지 못했습니다. 아마도 Joe는 다른 사람들의 코드를 가진 팀에서 일하는 데 익숙하지 않습니까?

"이 코드 라인이 추가 된 이유"를 고려한 적이 있습니까? 그것을 도입 한 커밋을 찾아서 그 주석을보십시오. 프로덕션 환경에서만 커밋하는 경우 주석이 유용 할 정도로 구체적이지 않습니다.

또한 SVN보다 강력한 도구를 사용하는 것이 좋습니다. Joel Spoelsky의 http://hginit.com/ 에서 가능성에 대한 좋은 소개를 볼 수 있습니다 .

그는 수은을 사용하고 있으며 요즘에는 여러 경쟁자가 있습니다. Git은 매우 강력하며 https://github.com/ 에는 매우 유용한 도구가 있으며 무료 초보자 계정을 제공하므로 실제로 사용해 볼 수 있습니다.

Joe는 SVN에 대해 아는 것처럼 보이지 않고 지점, 태그 및 트렁크에 대해 알아 봅니다 ... 태그는 Joe가 원하는 것과 일치합니다. SVN 모범 사례에 대한 일부 독서는 아프지 않을 것입니다

SVN을 사용하지 않았 으므로이 절차가 무엇인지 알 수 없습니다. 우리는 ClearCase를 사용하고 있으며, 각 개발자는 자체 개발 브랜치, 테스트를 시작할 준비가되었을 때 통합하는 통합 브랜치, 통합 및 테스트 된 코드를위한 하나 이상의 릴리스 브랜치를 보유하고 있습니다. .

Joe는 개발자가 아닌 해커입니다. 그는 아주 좋은 해커처럼 들리지만 개정 제어를 사용하는 방법에 대해서는 틀 렸습니다. 그래서 어떻게해야합니까?

귀하의 조직은 SVN에 투자하고 있으며 Joe에게 도전하고 SVN 서버에 대한 달러 투자를 무효화하는 것이 경력을 제한하는 것 같습니다. GIT 저장소를 설정하고 git svn 인터페이스를 사용하여 원하는 방식으로 작업하십시오 (이것은 모두 무료 소프트웨어이며 워크 스테이션에서 설치하는 데 1 ~ 1 시간이 걸립니다). Joe와 함께 워크 플로우를 사회화하십시오. 그는 "오염되지 않은 SVN 저장소"신념 시스템을 보존하고 구석에있는 값 비싼 흰 코끼리 (및 자아)에 대한 신뢰를 유지할 수 있습니다.

나는 짧은 시간 안에 Joe가 당신의 일을보고 같은 일을 시작하기를 기대합니다. 1-2 년 후에 SVN 서버는 Git 저장소가 될 것입니다.

위의 주장으로 Joe를 설득 할 수 있습니다. 이것이 성공하지 못하면 자신의 개발 작업에 SVN을 로컬로 사용하고 Joe가 언젠가 그것을 선택하기를 바랍니다. 당신이 논쟁으로 그들을 설득 할 수 없다면 당신의 설득과 행동을 보여주십시오. 분산 된 접근 방식이지만 기존 툴링을 사용합니다.

여기서 @ Carson63000을 반향하고 이전에이 자세를 보았으며 VCS의 끔찍한 분기 / 병합 기능으로 인해 발생합니다. 각 릴리스에 대한 태그와 함께 테스트를 컴파일하고 통과하는 브랜치를 갖는 것은 훌륭한 접근 방법이지만 다른 코드가 커밋되지 않는 한 그렇게해서는 안됩니다. 일반적으로 DVCS, 특히 git은 분기를 쉽고 일반적인 작업으로 만들어이 워크 플로의 어려움을 크게 줄입니다.

버전 제어 시스템이 태그를 지원하는 이유는 인증 된 코드에 태그를 지정하고 일상적인 작업을 계속 수행 할 수 있기 때문입니다. 생산 품질 코드가있을 때마다 태그를 커밋하면 완료됩니다. 고객이 가진 것을 얻기 위해 돌아 가야하는 '시간'의 정확한 지점을 알고 있습니다. 또한 코드의 다른 버전을 항상 확인하고 비교할 수 있습니다. 이렇게하면 소스 제어 데이터베이스에있는 모든 것에 만족할 수 있습니다. 100 명의 개발자가 모두 같은 프로젝트에서 일하는 회사에서 일합니다. 그것은 또한 당신에게도 잘 작동합니다.

프로덕션에 제공 할 수있는 버전 제어 시스템에만 물건을 저장하는 것이 일반적입니다. 디스크 스토리지 비용이 메가 바이트 당 수백 달러에 달하고 모든 것을 저장하는 것이 너무 비싸기 때문에 과거 수십 년 동안 그랬습니다.

더 이상 일을하는 가장 좋은 방법으로 간주되지 않지만, 많은 이전 버전 제어 시스템이 여전히 사용 중이기 때문에 사람들이 여전히 왜 그렇게하는지 이해할 수 있습니다. 각 릴리스는 (또는 오히려 돌아 가야 할 경우 각 파일의 태그를 확인하지 않고 릴리스가 무엇인지 알 수있는 방법이 없습니다. 오래된 것을 되돌릴 수있는 유일한 방법은 여러 저장소를 보았습니다. 릴리즈는 리포지토리에서 해당 릴리스의 소스 코드 및 바이너리가 포함 된 zip 파일을 검색하는 것이 었습니다).