버전 제어 소프트웨어를 사용한 적이없는 개발자를 설득하려면 먼저 개의 질문에 답변 할 준비가되어 있어야합니다. 걱정할 필요가 없습니다. 다음과 같은 질문에 홍수가 올 것입니다.
- 이전에 작업 한 방식에 어떤 문제가 있었습니까? 우리는 전혀 문제가 없었어요! (더 자세히 조사 할 때, 그들이 가진 모든 종류의 문제에 대해 듣게 될 것이지만, 편리하게 잊어 버렸거나 문제로 인식하지 못했을 것입니다.)
- 사이트에 Google 제품을 어떻게 배포합니까?
- 내 물건은 어디에 보관됩니까?
- 왜 쉽게해야 할 일을하는 많은 추가 단계가 있습니까?
- 왜 이러한 장벽을 방해하고 있습니까? 내 일을 끝내야 해!
링크 된 질문에 대한 대답이 적합합니다. 당신은 다음을 시연해야합니다 :
- 개발자에게 : 이것은 언젠가 당신의 숨김을 저장합니다.
- 관리자에게 : 프로젝트에서 누가 무엇을하고 있는지 정확하게 추적 할 수 있습니다.
- 회계사에게 : 궁극적으로는 세이프 넷을 사용하여 (배가 고갈되는 경우) 개발자가 개발 중이거나 배포하지 않는 시간을 절약 할 수 있습니다.
- 시스템 관리자에게 : 이것은 개발자를 서버에서 보호 할 것입니다.
버전 관리 (Subversion 또는 기타)를 설치하고 하루 만 호출 할 수는 없습니다. 사람들은 쉽게 이전 방식으로 되돌아갑니다 (아마도 그렇지 않은 것 같습니다.). 소스 & 구성 관리 및 워크 플로 및 추적 요구 사항을 지원하는 프로세스를 설계해야합니다.
적어도 두 개의 완전하고 분리 된 환경 (dev & 생산)이 있어야합니다. 3 개 (dev : 준비, & 생산)가 맞습니까? 그렇지 않다면 거기에서 시작하십시오. 사람들이 라이브 웹 사이트를 무작위로 변경해서는 안됩니다! 그리고 가능한 경우 개발자는 자신의 프로젝트를 워크 스테이션에서 바로 실행할 수 있어야 체크인하기 전에 테스트 할 수 있습니다.
응용 프로그램은 완전히 자체 구성되어야합니다. 즉, 특정 환경에 배포 할 때마다 수동으로 수동 조작하지 않아도됩니다. 배포는 어느 정도 "손을 떼야"하거나 적어도 스크립팅되어야합니다. 설정을 완료 한 후에는 배포를 처리하기 위해 자체 스크립트, Continuous Integration 시스템 또는 둘의 조합이 필요합니다.
개발자 환경에서 웹 사이트를 업데이트하려면 use a post-commit hook script 수 있습니다. 따라서 개발자가 변경 사항을 커밋하는 즉시 개발자 사이트로 이동하여 보게됩니다.
내 자신의 설정은 이렇게 있습니다 :
- CruiseControl.NET 내가에 배포하는 각 서버에서 실행됩니다.
- dev 서버의 CCNET 서비스가 변경 사항을 선택하고 SVN에서 프로젝트를 가져오고 &을 Tomcat 응용 프로그램 서버 (Java 웹 응용 프로그램)에 배포합니다.
- 성공적인 배포 후에 CCNET은 방금 배포 한 코드를 나타내는 태그를 저장소에 만듭니다.
- 자체 테스트를 수행 한 후 준비 서버의 CCNET 구성이 생성 된 태그를 가리 키도록 업데이트되고 빌드가 강제로 수행됩니다.
- 준비가 완료되면 다른 태그가 만들어집니다.
- 최종 승인 테스트가 승인 된 후 프로덕션 서버에 대한 CCNET 구성을 업데이트하고 강제로 빌드합니다.
- 프로덕션 환경에서 성공적인 빌드가 완료되면 다른 태그가 만들어집니다.
내 CCNET 구성도 Subversion에 저장되고 CCNET을 통해 배포되므로 서버의 파일을 직접 만질 필요가 없습니다. 업데이트하고 커밋하고 트리거하여 업데이트 된 파일을 가져옵니다. 해당 서버로 구성하십시오.
모든 태그가 제공하는 것은 무엇입니까?
- 문제가 발생하면 이전에 알려진 양호한 상태로 각 환경을 롤백 할 수 있습니다.
- 기능 세트 B가 예정된 유지 관리 기간 동안 프로덕션으로 승격되기를 기다리는 동안 기능 세트 B에 대한 개발을 진행할 수 있습니다.
RedGate의 Deployment Manager와 같은 다른 도구를 사용하면 훨씬 더 자동으로 만들 수 있습니다.
이 모든 작업을 수행하려면 모든 사람이 따르는 확실하고 동의 된 프로세스가 필요합니다. separation of duties을 사용하는 것이 좋습니다. 개발자가 배포하지 않아야하며 관리자가 코드를 배제해서는 안됩니다.
OK, 모든 것을 설정 했으므로 모든 사람 (관리!) 그들이 타고 있다고 말하면 다음은 무엇입니까?
모든 개발자를위한 비 개발 서버에 대한 액세스 권한을 취소합니다. 더 이상의 FTP, 더 이상의 쉘, 없음. 일부 로그에 대한 읽기 전용 액세스 권한이있을 수 있습니다.
그들은 울 것입니다. 그들은 겁을 먹을 것이다. 그들은 당신에게 화를 낼 것입니다. "내 모든 액세스를 빼앗아 가고 있습니다!" "너는 내 길을 가고있다!" "이것은 간단한 변화를 만들기 위해 10 배 더 걸릴 것입니다!" "너 괴물이야!" "너는 사탄을 정말 좋은 사람처럼 보이게 만든다!"
과 상관 없습니다. "쉬운 방법"이있는 한 올바른 방법은 무시됩니다. 이런 이유로 당신은 온보드 관리가 필요하며 등을보아야합니다.
실시간 트래픽 부하가 너무 커서 무언가가 처음으로 생성되어 데이터베이스 서버가 다운되면 이전 버전의 앱으로 되돌아 가서 5 분 안에 정상 상태로 돌아갑니다. 당신은 영웅이 될 것입니다.
"분기하기 전에 .svn 항목을 제거해야합니다."라는 말은 걱정입니다. 당신이 당신의 프로세스를 잘못 설명하고 있거나, 당신이 뭔가 잘못하고있다.
편집 : 그냥 다른 것을 기억합니다. 저장소에 대한 백업 전략을 얻었습니까? 그렇지 않은 경우 드라이브가 데이터 손실로 실패하면 & Subversion이 고장난 하드웨어가 아닌 모든 곳에서 훼손됩니다 (하드웨어 오류가 어디에서나 발생할 수 있음에도 불구하고).
SCM을 사용하여 새로운 팀을 구성 할 때 가장 큰 문제는 '실행 취소'변경 사항의 내보내기/가져 오기 오용입니다. 초보자는 역 병합을 활용하는 대신 파일을 다시 가져 오는 경우가 많습니다 (일반적으로 내 경험에 대한 교육 부족). '역 병합'대신 '다시 가져 오기'가 어색하고 사용자 경험이 좋지 않습니다. 그 결과 '우리는 FTP에 이러한 문제가 없었습니다!' 불만. – Josh