버전 관리 채택을 장려하는 방법

최근에 버전 관리가없는 팀에서 일하기 시작했습니다. 대부분의 팀원은 어떤 종류의 버전 관리에도 익숙하지 않습니다. 나는 개인적으로 수은을 사용하여 일을 추적 해 왔습니다. 나는 다른 사람들이 그것을 채택하도록 격려하고 최소한 변화를 일으킬 때 코드를 버전 화하기 시작하고 싶습니다. 누구든지 수은과 같은 분산 버전 제어의 채택을 장려 할 수있는 방법에 대한 조언을 줄 수 있습니까? DVCS에 관리자를 포함하여 사람들을이기는 방법에 대한 조언은 대단히 감사하겠습니다.

버전 관리를 사용하기위한 사례를 만들고 먼저 동료에게 판매를 시도하고, 실패한 경우 리더십을 높이기위한 체인을 구축하십시오.

동료 소프트웨어 엔지니어에게는 장기적으로 시간과 두통을 줄이는 방법에 중점을 두어야합니다. 버전 관리를 사용하여 삶을 편하게 만드는 방법에 대한 과거 또는 출판 된 이야기 (블로그, 잡지 기사, 백서)에서 시간을 찾으십시오. 버전 관리 기능이 없어서 화상을 입었다면 개인적으로 만드십시오. 동료 개발자가 같은 상황에 처해 있었다면 조명을보고 이러한 도구가 어떻게 도움이되는지 확인해야합니다.

이것은 최선의 방법입니다. 지금은 소스를 찾을 수 없지만 가장 효과적인 프로세스 변경 사항은 개발자가 변경 사항을 처리해야한다는 점을 읽었습니다. 개발자가 참여할 수 있다면 두 가지를 달성 할 수 있습니다. 먼저, 프로세스 변경에 영향을받는 사람들로부터의 바이 인이 이미 있습니다. 둘째, 경영진에게 이것이 가치있는 노력이며 제품과 프로젝트를 개선 할 것이라고 확신시키는 사람들이 있습니다.

그러나 개발 팀의 지원을받을 수없고 여전히 버전 제어 배포에 대해 매우 강한 느낌이 든다면 관리 부서로 넘어갈 수 있습니다. 그러나 혼자서 나가면 개선에 대한 걱정뿐만 아니라 동료의 반발에도 대처할 수 있으므로 위험합니다.

프로젝트, 프로그램 및 조직 관리를 위해서는 버전 제어를 배포하여 조직의 시간과 비용을 절약 할 수있는 방법이 필요합니다. 이 수준의 사람들은 프로젝트 비용이 얼마나 드는지, 견적과 비교하여 어디에 있는지 등을 걱정합니다. 버전 관리를 배포하여 다른 조직이 장기적으로 시간과 비용을 절약 한 방법을 설명하는 백서, 서적, 기사 및 기타 전문 문서 및 출판물을 찾아보십시오. 조직에서 소프트웨어 품질에 관심이있는 경우 여기에 품질 관점을 도입 할 수도 있습니다.

분산 버전 제어 시스템을 사용한다고 구체적으로 언급했습니다. 팀이나 조직의 목을 강요하지 마십시오. 버전 관리 및 옵션을 소개하십시오. 개인적으로 DVCS (예 : Mercurial)를 선호하지만 팀과 조직에 가장 적합하지 않을 수 있습니다. 적합하지 않은 도구를 사용하면 스 래싱을 통해서만 문제가 악화됩니다.

또한 프로세스를 늦게 도입 할 위험에주의하십시오 . 버전 관리를 사용하는 것이 일반적으로 가장 좋은 방법이지만 프로젝트 완료에 큰 위험없이 현재 프로젝트에 효과적으로 도입하기에는 너무 늦을 수 있습니다. 대신, 나는 미래의 프로젝트와 팀을위한 현 상태 개선에 중점을 둘 것을 권장합니다.

또한 이것은 프로세스 또는 기술 향상을 수행하기 위해 따를 수있는 일반적인 접근 방식입니다.

첫 번째 질문은 현재 무엇을 하는가입니다. 분명히 각 개발자는 자신의 상자에 소스 코드가 붙어 있지 않아 마음대로 변경할 수 없습니다. 현재 진행중인 프로세스가 있으면이 프로세스를 향상시키는 몇 가지 도구를 제안 할 수 있습니다. 일반적으로 SCM은 다른 프로세스를 따르지 않고이를 지원하는 데 이상적입니다.

여기서 중요한 점은 의사 SCM 작동 방식이 있거나 어딘가에 서버에 현재 버전을 저장 한 경우 DVCS 또는 CVS가 더 적합한 지 확인해야한다는 것입니다. SVN이 더 적합하다면.

가장 빠른 방법은 경영진에게 필요한 것을 확신시키는 것입니다.

몇 가지 계산을 수행하십시오.

버전 관리 소프트웨어 비용-무료
리포지토리를 지원하는 하드웨어 비용-하나의 서버
소프트웨어 구현 비용-소규모 팀에게는 며칠이 걸리고 대규모 팀은 증가합니다.

버전 관리를 구현하지 않는 비용 :

가장 좋은 경우-수정 사항 누락, 서로의 변경 사항 덮어 쓰기, 버그 반복 등으로 인해 손실 된 일수.
최악의 경우-그러나 수년간의 노력으로 팀이 지금까지 소비했습니다.

이 후자의 그림은 서버 장애 등으로 인해 모든 작업이 손실되는 최악의 시나리오이지만 "최상의 경우"시나리오조차도 필요한 이유를 파악해야합니다. 반복되는 버그 비용은 고객 손실로 이어질 수 있으므로 더 커질 수 있습니다.

개발팀은 또한 이러한 비용을 이해하고 요즘 대부분의 버전 제어 소프트웨어가 IDE와 매끄럽게 통합된다는 점을 감안할 때 대부분의 경우 그 사실을 알지 못할 것입니다.

경영진은 일반적으로 돈을 절약하는 데 가장 관심이 있습니다. 버전 관리가 팀에 재정적으로 도움을 줄 수있는 방법을 강조하면 바로 관심을 끌 수 있습니다!

분산 된 버전 제어 에 대해 이야기하고 있다고 생각하는 다른 사람들이 여기에 대해 언급하지 않은 한 가지 측면이 있습니다. 그 본질 상, 실제로는 한 명의 개발자가 될 수 있습니다. 한 번에. 우리가 내 사무실에서 사용하는 것과 같은 더 복잡한 버전 제어 (MS Visual SourceSafe)를 사용하면 큐브를 통해 다른 사람과 함께 일하는 데 어려움을 겪을 수 있습니다. 버전 관리. 그러나 DVCS를 사용하면 "이봐, 이것을 시도해보고 마음에 드는지 알 수 있습니다. 나는 밧줄을 보여줄 것입니다. 나는 질문에 대답하고, 당신을 안내하고, 행복하게 할 것입니다." blah ". 그렇게하면 높은 수준에서 "프로세스"가 필요하지 않으며 한 번에 한 사람 씩 풀뿌리 명령을 작성할 수 있습니다.

gbjbaanb의 답변을 기반으로합니다.

여기서 중요한 것은 기존 프로세스에 따라 버전 제어 프로세스를 조정하고 나머지 팀 노력을 어떻게 절약하는지 보여 주어야합니다.

나는 개인적으로 Mercurial을 선호하지만 버전 제어에 익숙하지 않은 사람들에게 구식 서버 기반 잠금 버전 제어 시스템보다 이해하기가 조금 더 어렵 기 때문에 필연적으로 그것을 원치 않을 것입니다. 그것은 진정한 그린 필드 사이트라면 전체 돼지를 가고 80 년대와 90 년대를 건너 뛰고 Mercurial과 함께하는 것이 가장 좋을 것이라고 말했습니다. 또한 Mercurial을 중심으로 구축 된 타사 소프트웨어 라이프 사이클에 대한 내용도 살펴볼 것입니다.

나는 당신이 소규모 회사에서 일하고 있고 당신이 팀에 대해 비교적 새롭기 때문에 어려운 판매가 될 수 있다고 생각합니다. 물건을 심하게 채우고 구출하는 것이 가장 좋습니다. 그것은 방해를 의미하는 것이 아니라 피할 수없는 것을 기다립니다.