카우보이 프로그래머에게 소스 제어를 사용하도록 설득하려면 어떻게해야합니까?

업데이트
나는 4 명의 작은 개발자 팀에서 일하고 있습니다. 그들은 모두 소스 컨트롤을 사용했습니다. 대부분은 소스 제어를 견딜 수 없으며 대신 사용하지 않도록 선택합니다. 저는 소스 컨트롤이 전문 개발의 필수 부분이라고 믿습니다. 몇 가지 문제로 인해 소스 제어를 사용하도록 설득하기가 매우 어렵습니다.

• 이 팀은 TFS 사용에 익숙하지 않습니다 . 나는 두 번의 훈련 시간을 가졌지 만 1 시간 밖에 할당되지 않아서 충분하지 않았다.
• 팀 구성원은 서버에서 코드를 직접 수정합니다. 이렇게하면 코드가 동기화되지 않습니다. 최신 코드로 작업하고 있는지 확인하기 위해 비교가 필요합니다. 복잡한 병합 문제가 발생합니다
• 개발자가 제공 한 시간 추정치는 이러한 문제를 해결하는 데 필요한 시간을 제외합니다. 따라서, 내가 nono라고 말하면 10 배 더 오래 걸릴 것입니다 ...이 문제를 지속적으로 설명하고 위험을 감수해야합니다. 이제 경영진이 나를 "느린"것으로 인식 할 수 있기 때문입니다.
• 서버의 실제 파일은 ~ 100 개의 파일에서 알 수없는 방식으로 다릅니다. 병합에는 현재 프로젝트에 대한 지식이 필요하므로 개발자가 얻을 수없는 개발자 협력이 필요합니다.
• 다른 프로젝트가 동기화되지 않습니다. 개발자는 소스 제어에 대한 불신을 계속 유지하므로 소스 제어를 사용하지 않음으로써 문제를 복잡하게 만듭니다.
• 개발자들은 병합이 오류가 발생하기 어렵고 소스 제어를 사용하는 것이 낭비라고 주장합니다. 소스 제어가 잘못 잘못 사용되고 소스 제어가 계속 우회 될 때 오류가 발생하기 쉽기 때문에 이는 논란의 여지가 없습니다. 그러므로 그 증거는 그들의 견해에서 "자체를 말한다".
• 개발자는 TFS를 무시하고 서버 코드를 직접 수정하면 시간이 절약된다고 주장합니다. 이것 또한 논쟁하기 어렵다. 병합 코드 동기화하는 데 필요한 때문에 시작하는 시간이 소요입니다. 우리가 관리하는 10 개 이상의 프로젝트에 이것을 곱하십시오.
• 영구 파일은 종종 웹 프로젝트와 동일한 디렉토리에 저장됩니다. 따라서 게시 (전체 게시)는 소스 제어에없는 파일을 지 웁니다. 또한 소스 제어에 대한 불신을 유발합니다. "게시하면 프로젝트가 중단됩니다". 이 위치를 수정하면 (저장된 파일을 솔루션 하위 폴더에서 제거)이 위치가 web.config에 설정되어 있지 않고 여러 코드 포인트에 존재하기 때문에 디버깅하는 데 많은 시간과 시간이 걸립니다.

따라서 문화는 계속 유지됩니다. 나쁜 습관은 더 나쁜 습관을 낳습니다. 나쁜 솔루션은 새로운 핵을 만들어 훨씬 더 깊고 시간이 많이 걸리는 문제를 "수정"합니다. 서버, 하드 드라이브 공간은 오기 어렵습니다. 그러나 사용자의 기대치는 높아지고 있습니다.

이 상황에서 무엇을 할 수 있습니까?

그것은 훈련 문제가 아니라 인적 요소 문제입니다. 그들은 원하지 않고 도로 ​​블록을 만들고 있습니다. 부서진 집단의 역학을 다루는 것은 그들의 반대의 근본 원인 인 것입니다. 일반적으로 두려움은 변화에 대한 두려움 일뿐 아니라 더 사악한 것입니다.

오늘날 또는 지난 20 년 동안 전문 개발자는 소스 제어에 저항하지 않았습니다. 약 30 년 또는 40 년 전, 컴퓨터가 느리고 소스 제어가 느리고 프로그램이 하나의 500 줄 파일로 구성되어 있었을 때 고통스럽고 사용하지 않는 정당한 이유가있었습니다. 이 반대는 내가 생각할 수있는 최악의 카우보이에게서 나올 수 있습니다.

어떤 식 으로든 그들의 삶이 어려워 지도록 시스템이 강제되어 있습니까? 내용을 확인하고 이의를 무효화하도록 시스템을 변경하십시오. 끝날 때까지 반복하십시오.

GIT 또는 Mercurial을 살펴볼 것을 제안합니다. 각 소스 코드 트리에 리포지토리를 만들 수 있으며, 지금도 눈치 채지 못하고 해킹을 계속할 수 있습니다. 코드베이스에 해킹 한 변경 사항을 추적하고 커밋하고 다른 소스 트리에 병합하는 등의 작업을 수행 할 수 있습니다. 몇 초 동안 다른 제품에 몇 주 간의 노력을 기울이면 아이디어가 바뀔 수 있습니다. 하나의 명령으로 나사 업 중 하나를 롤백하고 엉덩이를 저장하면 감사 할 수도 있습니다 (믿지 마십시오). 최악의 경우, 당신은 상사 앞에서 좋아 보이고 보너스로 그들이 카우보이처럼 보이게합니다.

합병은 프로젝트에 대한 훌륭한 지식뿐만 아니라

이 경우, 당신이 노를 쓰지 않고 잠정적 인 개울에 올라가는 것이 두렵습니다. 병합이 옵션이 아닌 경우 옵션도 구현하지 않으므로 한 지점에 이미있는 기능 (느슨하게 사용 된 용어)을 다른 지점에 더 이상 추가 할 수 없습니다.

내가 너라면 내 직업 전망을 재고 할 것이다 ...

때로는 실제 문제로 인해 사용하기가 불가능한 경우가 있습니다.

그릇된.

팀이 소스 제어를 사용하는 데 익숙하지 않으면 훈련 문제가 발생할 수 있습니다

그것은 소스 코드 제어와 관련이 없으며 교육과 관련이 있습니다. 교육은 쉽고 저렴하며 효율적이며 몇 시간 안에 완료됩니다. 소스 코드 제어를 사용하지 못하는 것은 비용이 많이 들고 위험하며 비효율적이며 문제는 영원히 지속 됩니다 .

팀원이 서버의 코드를 직접 수정하면 다양한 문제가 발생할 수 있습니다.

이것이 훈련 문제입니다. 다시. 소스 코드 제어와 관련이 없으며 교육과 관련이 있습니다.

개발자는 소스 제어에 대한 불신을 계속하여 소스 제어를 사용하지 않음으로써 문제를 복잡하게합니다.

소스 코드 제어를 사용하는 방법에 대해 교육을 받아야합니다. 비용을 줄이고 위험을 줄이며 업무를 단순화하고 더 효율적입니다. 매 순간 배당금을 지불하는 일회성 투자입니다.

이런 상황에서 무엇을 할 수 있습니까?

소스 코드 제어를 사용하는 방법에 대한 모든 사람을 교육하십시오.

최신 정보

개발자는 소스 제어를 직접 수정하면 시간이 절약된다고 주장합니다.

그것들이 틀리기 때문에, 이것이 얼마나 잘못되었는지를 정확하게 나타 내기 위해 데이터를 수집하는 것이 중요합니다.

그러나 안타깝게도 경영진은 장기적으로 비용이 많이 드는 즉각적인 대응을 보상하는 것으로 보입니다.

이 보상 시스템을 극복하는 유일한 방법은

A) 장기 비용이 명백한 단기 가치보다 높다는 것을 식별하십시오 .

B) 단기적인 손상 (즉, 직접 변경)이 장기적인 올바른 소스 코드 제어보다 더 가치있는 것처럼 보이게하는 실제 보상을 식별하십시오. 누가 잘못된 일을해서 머리를 두드리는가? 그들은 머리에 어떤 종류의 팻을 얻습니까? 누가 그것을 제공합니까? 사물을 고치려면 잘못한 사물과 실제로 사람들을 격려하는 특정 관리자의 이름을 지정해야합니다.

C) 단기적인 빠른 대응 대신 장기적인 가치를 중시하는 수정 된 보상 시스템을 권장합니다. 다른 이유로 머리에 다른 pats.

D) 장기적인 가치에 대한 보상으로 사람들을 훈련시킨다. 단기 빠른 응답보다 분명히 큰 가치.

소스 / 버전 제어 사용을 거부하는 개발자는 그렇게 간단하게 해고되어야합니다. 이미 지적했듯이, 사용하지 않을 때의 고유 한 위험과 비용은 많은 규모의 오버 헤드보다 더 큽니다. 이 문제에 반대하는 사람은 단순히 소프트웨어 개발에 관여해서는 안되며 그러한 사람들과 일하기를 거부 할 것입니다.

먼저 소스 제어를 개발에 적용하기 위해 지속적인 통합 서버를 설정하여 문제를 해결했습니다. 둘째, 사람들이 소스 제어를 피하고 파일을 직접 수정하지 못하도록 폴더 액세스를 읽기 전용으로 잠급니다.

현지에서 버그를 재현 할 수없는 요일의 PITA이지만 CI 서버가 자동으로 개발자에게 푸시한다는 사실을 알고 작업, 체크인 및 이동이 더 좋습니다.

당신의 고통이 들립니다. 나는 '소스 제어'가 네트워크 드라이브의 공유 폴더라는 것을 알기 위해 두 곳의 작업장으로 들어갔습니다. 문제는 일반적으로 접근 방식이 다른 방법보다 우수하다고 생각하기 때문에 발생하지 않으며 단순히 작동하며 소스 제어를 성공적으로 통합하는 워크 플로에 도입 된 적이 없습니다.

평평한 지구 팀 구조를 사용하면 위에서 아래로 밀어 넣는 것이 상황에 접근하는 가장 좋은 방법이 아닐 수 있다고 설명했습니다. 시도해 볼 가치가있는 방법 중 하나는 다른 개발자 중 한 명 또는 두 명으로부터 직접 구매하여 개념이 모멘텀을 모을 수 있도록하는 것입니다. 보드에 다른 개발자가 있으면 팀의 나머지 팀에게 배포하는 것이 훨씬 쉽습니다. 개념을 천천히 소개하고, 작은 프로젝트에서 작업을 시작 하거나, Git 에서 시작하고 , GitHub에서 호스팅되는 것을 분기한다고 말합니다 .

간단하게 시작하고 개념을 일상적인 워크 플로와 느리고 개별적으로 소개하십시오. 인간은 사물을 배우고 변화에 적응하는 데 능숙합니다. 특히 그러한 변화가 그들에게 직접적인 이익을 제공 할 때 (진화를 생각하십시오). 그러나 한 번에 많은 작은 변화가 나타나면 소외됩니다. 소스 제어의 작동 방식과 장점을 파악한 후에는 내부 프로젝트 중 하나에 통합을 시도해보십시오 (새 프로젝트를 시작하는 경우이 프로젝트를 소개하는 것은 사악한 시간입니다). 원하는 경우 다른 프로젝트가 기존 방식으로 작동하게하십시오. 이는 적절한 코드 제어의 장점을 강조하는 데 특히 효과적입니다.

실패하면 실행하십시오.

당신은 분명히 당신의 상황을 식별하고 고칠 수있는 기술적 인 능력을 가지고 있으며, 당신의 문제는 인간적이고 프로세스와 관련이 있습니다.

사람들은 비전보다 모범에 훨씬 더 잘 반응하는 경향이 있으므로 직접 "고정"하는 것이 좋습니다.

최신 소스의 사본을 가져 와서 버전 관리에 적합하도록 재구성하고, 유용하고 미래 지향적 인 구조로 새 프로젝트를 만듭니다 (분기를 처리하는 방법, 타사 종속성을 배치하는 방법 등). 당신은 아마 당신 자신의 시간에 그렇게해야 할 것입니다.

그런 다음 동료와 관리자를 회의실로 끌어서 21 세기의 소프트웨어 개발 모습을 보여 주십시오. 현재 시스템의 고장을 설명하고 새로운 구조로 어떻게 제거되는지 보여줍니다.

당신은 또한 자신을 근원의 수호자로 설정해야합니다-당신이 걱정하는 유일한 사람 인 것처럼 보이기 때문에, 사람들을 (기술적 또는 심리적 수단으로 처분 할 수있는) 강제로 지키는 것은 당신에게 달려 있습니다. 계획. 있는지 확인 에만 고객에가는 일이 소스 제어에서 빌드 시스템에서왔다. 규칙을 어 기고 혼란을 일으키는 사람들을 의식적으로 굴욕하십시오. 도넛으로 뇌물을주세요.

그 모든 것이 너무 많은 노력으로 보인다면 (다른 모든 답변에서 언급했듯이) 다른 직업을 얻으십시오. 그들은 당신의 시간 가치가 없습니다.

1 단계-무능한 관리자를 해고하십시오!

1 단계를 수행 할 수 없으면 관리자가 소스 제어에서 가져온 스크립트로만 배치하도록 배치를 제한하도록하십시오. prod에 대한 제작 권한이 없어야하는 개발자가 배포하려면 1 단계를 참조하십시오. 개발자는 소스 제어에서 가져와야합니다. 이를 통해 소스 컨트롤을 사용하지 않는 문제를 C # 코드뿐만 아니라 데이터베이스 항목에 처음 사용할 때 문제를 해결했습니다.

다른 버전의 파일과 차이점을 볼 수있는 기능을 원하지 않는 사람은 무엇입니까? 분기와 복잡한 것들을 잊어 버려라. 그들은 기본조차 얻지 못합니다. 테스트 환경에서 가장 기본적인 변경을 수행하지 않고 프로덕션 파일을 직접 수정하는 것은 미친 짓입니다. 나는 몇몇 개인들과 함께 일해 왔으며 고맙게도 같은 프로젝트를 수행 한 적이 없습니다.

당신의 동료들은 너무 어리석어 서 게으르지 않습니다. 그것은 시간 낭비입니다. 당신이 할 수있는 것은 관리자를 훈련시키는 것입니다. 관리는 모든 형태의 제어를 좋아하기 때문에 소스 제어를 좋아해야합니다. 그들에게 중요한 느낌을줍니다. 다른 사람을 조이십시오. 당신이 그를 대체 할 수 없기 때문에 지도자를 고치는 것이 유일한 희망입니다. 다른 유능한 개발자와 네트워킹을 시작하고 개점시 팀에 합류 시키거나 상점에서 고용하도록하십시오.

이것은 나쁜 관행이 널리 퍼져서 실제로 고칠 수없는 프로젝트의 좋은 예입니다. 그것을 고치려면 동결이 필요하므로 중단없이 모든 것을 정리할 수 있습니다. 불행히도, 그러한 프로젝트는 일반적으로 몇 개월 동안 얼어 붙기에는 너무 까다롭기 때문에 중요한 버그는 격일로 수정해야합니다.

더티 버전은 매일 버그 수정으로 처리되는 동안 깨끗한 버전을 만들기 위해 프로젝트를 포크하려고 할 수도 있습니다. 그러나 가장 깨끗한 결과는 몇 달이 지난 후 "깨끗한"버전이 완성되면 아무도 포크 이후 어떤 버그 수정 및 변경 사항이 영향을받지 않았는지 알 수 없다는 것입니다. 변경 사항에 대한 기록을 유지합니다). 클린 버전은 구식이며, 더티 버전은 여전히 ​​작동합니다. 어떻게됩니까? 깨끗한 버전이 버려지고, 그 답은 입증되었습니다.

명백한 새로운 직업 찾기 외에는 그 답이 위의 모든 것 같아요.

먼저 관리 부서에 가서 소스 제어를 사용하고 시행하도록합니다. 그런 다음 서버에서 직접 작업하는 경우에도 작업을 계속 실행하기 위해 수행해야 할 작업을 수행하십시오. 소스 제어에서 모든 것을 얻는 프로세스를 시작하십시오.

다른 옵션은 최신 버전이 서버에 있는지 확인하고 (이것은 관계없이해야 함) 최신 저장소에서 새 저장소를 모두 시작하는 것입니다. 당신은 역사를 잃을 것이지만, 지금은 작은 감자입니다.

설명에 따르면 상황에 하나 이상의 문제가있는 것 같습니다. 개발자 팀이 제어 할 수 없거나 잘못된 소스 제어 솔루션이 구현되었습니다. 어느 쪽이든, 개발자 팀은 소스 제어 솔루션을 사용해야합니다. 프로덕션 서비스에서 소스 코드를 직접 수정하는 것만으로도 문제가 발생할 수 있습니다.

내 경험에 비추어 볼 때 가장 먼저해야 할 첫 번째 단계는 프로덕션 서버와 소스 제어를 동기화하는 것입니다. 이 단계는 프로덕션 코드 사본을 가져와 체크인하는 것만 큼 간단 할 수 있습니다. prod 코드는 아마도 팀이 개발하고있는 기초 일 것입니다. 이 단계는 기존 소스 제어 시스템에 떠있는 코드와의 병합으로 기능을 보강해야 할 수도 있습니다. 코드는 개발에서 통합 / QA (또는 둘 다)로 이동 한 다음 단계 또는 단계 / 생산으로 이동해야합니다.

다음으로 경영진은 소스 제어 사용을 의무화해야합니다. 간단히 말해, 빌드가 소스 제어 시스템에서 나온 것이 아니라면 코드를 프로덕션 환경에 배포해서는 안됩니다. 프로덕션 액세스 문제는 개발팀으로 만 제한해야하며 프로덕션 문제를 해결하기 위해 개발자에게 액세스 권한이 제한됩니다. 개발자는 일반적으로 프로덕션에 코드를 과도하게 배포해서는 안됩니다. 특히 개발자가 압박을받는 경우 프로덕션 문제가 발생할 수 있습니다.

경영진은 여기서 문제를보다 잘 처리해야합니다. 코드가 직접 제품에 적용되고 소스 제어에 들어 가지 않으면 개발을 유지하는 것이 거의 불가능합니다.

실제 문제는 카우보이 코더가 버전 제어를 사용하지 않는다는 것입니다. 진짜 문제는 그들이 이미 어떤 일을하는 방법을 선택했고 그들의 프로세스를 바꾸려고한다는 것입니다. 선택된 프로세스는 버전 관리를 포함하지 않습니다. 프로그래머 스스로 문제를 발견하지 않으면 모든 프로세스 변경이 어렵습니다. 기존 시스템이 충분하다고 생각되면 다른 시스템을 강요하는 것은 쓸데없는 일입니다. 우리는 보그입니다, 당신은 동화 될 것입니다. 물론 그들은 보그가되기 위해 싸우려고 노력하고 있습니다.

자신의 건강을 위해 Git 또는 다른 DVCS를 자신의 컴퓨터에 설정하여 변경 사항을 추적하는 것이 좋습니다. 동료의 변경 사항을 저장소로 자주 가져 오십시오. 최선을 다해 갈등을 해결하십시오. 이것은 동료의 광기에서 부분적으로 당신을 보호합니다.

당신은 경영진이 개발자들이 소스 컨트롤을 사용해야한다고 말했다. 악의적 인 경우 TFS의 변경 사항을 확인하고 정기적으로 저장소를 게시하여 TFS에없는 변경 사항을 클로버하여이를 적용 할 수 있습니다. (자신의 DVCS도 유지 관리하는 경우 두 개의 동기화를 유지해야합니다.) 그렇게하는 이유는 관리 부서의 명령을 따르는 것입니다. 동료가 변경 내용을 덮어 쓰는 데 지치면 TFS를 사용하도록 초대하십시오. 체크인되지 않은 변경 사항을 계속 유지하십시오. 동료가 회복되거나 해고 될 때까지 계속하십시오.

개발 이외의 서버를 잠급니다. 구성 관리자를 사용하십시오. 태그에 대해 정기적으로 식별 가능한 빌드를 수행하십시오. 모든 변경 세트에 태그를 지정하십시오 (예 : 버그 당 1 개의 변경 세트). 또한 각 빌드에 태그를 넣습니다. 개발자와 프로덕션간에 QA 유형 시스템이 있어야합니다 (최소한). 올바른 빌드 태그를 사용하여 품질 관리 시스템에 빌드하십시오. "빌드 깨기"에 대한 슬픔을주세요.

나는 (생산에만 표시되는) 문제를 다시 만들거나 해결할 수없는 상황에 처한 적이 없다. 예, 개발 시스템에서 문제를 재현하는 데 몇 시간을 보냈습니다. 또한 문제를 파악하면 회귀 테스트에 추가 할 수 있습니다.

우리는 그 모든 나쁜 일을 한 카우보이 계약자들과 프로젝트를했습니다. 그 후 4 주를 정리 한 다음 위의 관행을 제자리에 두었습니다. 그 이후로 프로젝트에는 아무런 문제가 없었습니다.

인용문:

이 팀은 TFS 사용에 익숙하지 않습니다

TFS는 Microsoft Team Foundation Server로 밝혀졌습니다.

첫 번째 본능은 "이것은 Microsoft Visual SourceSafe의 최신 릴리스입니다"라고 말합니다.

나는 당신 동료의 편에 서서 정말 반대합니다.