소스 제어로 이동

우리는 약 100 개 이상의 웹 사이트에 기능을 제공하는 단일 목적 PHP 웹 앱을 개발하는 상당히 작은 회사 (3-4 프로그래머 및 3-4 사이트 디자이너)입니다. 우리는 상당히 잘 작동하는 별도의 개발 및 프로덕션 환경에서 몇 년 동안 운영했습니다. 프로그래머가 실제로 충돌하지 않도록 개발할 수있는 별도의 기능이 항상 충분했으며 소스 제어없이 작업하는 것이 더 편리했습니다. 데이터 손실의 위험이 있었지만 실수로 파일을 공유 할 때 상당한 부분이 누락되었습니다.

다른 고려 사항은 우리 디자이너가 기술에 정통하지 않다는 것입니다 (WYSIWYG를 사용하는 대신 HTML 마크 업에 소개했습니다). 이것이 버저 닝으로 이동하는 것을 망설이는 이유 중 하나였습니다.

그러나 이제 100 개 이상의 사이트에 도달했으며 개발 팀이 커지고 있으므로 절차를 표준화하려고 노력하고 있으며 소스 제어는 프로그래머가가는 한 논리적 단계로 보입니다. 패치 배포 속도도 향상되기를 바랍니다.

불행히도 소스 제어 시스템 설정에 대한 경험이 매우 제한적입니다. 비슷한 설정을 가진 사람들로부터 들리거나 스위치를 만든 경험이 궁금합니다.

1) 모든 것 (사이트, CSS, html 템플릿 및 앱 코드)의 버전을 지정하여 디자이너가 버전을 학습하도록 강요합니까? 아니면 응용 프로그램 코드에서 작업하는 개발자일까요?

2) 소스 컨트롤을 처음 설정할 때주의해야 할 몇 가지 함정은 무엇입니까?

3) 소스 제어를위한 dev => 생산 팁 배포.

모든 통찰력에 감사드립니다.

편집 1 : Dang. 지금까지 모든 사람이 모든 것을 통제 할 것을 권장하고 있습니다. 머리가 빨리 빠질 것입니다. 아마 가까운 장래에 새로운 질문이 생길 것입니다. 지금까지 조언에 감사드립니다. 계속 오십시오!

편집 2 : 좋은 답변이 많이 있으며 다양한 버전 제어 시스템을 살펴볼 것입니다. 답장을 보내 주셔서 감사합니다!

디자이너조차도 모든 버전을 관리하는 것이 도움이됩니다. 그리고 훌륭한 교육으로 제대로 구현하면 부담이되는 것보다 도움이 될 것입니다.

방금 시작한 경우 git 또는 mercurial 과 같은 분산 버전 제어 시스템을 사용하는 것이 좋습니다 . 이것이 세상의 일반적인 추세이며 많은 장점이 있습니다. 네트워크 의존성과 연결되지 않은 비공개 작업을 여전히 버전 관리하에 수행 할 수있어 연결이 끊긴 모드에서 쉽게 작업 할 수 있으며, 준비가되면 중앙에서 모든 것을 확인합니다.

그리고 권위 나 다른 것에 호소하지 말고 Joel Spolsky가이 주제에 대해 무엇 을 말해야 하는지 확인하십시오 . (선택 인용문 : "Subversion = Leeches. Mercurial and Git = Antibiotics.")이 새로운 시스템은 기존의 버전 관리와는 다른 새로운 정신 모델을 사용한다는 흥미로운 점을 제시합니다. 처음부터 접근은 승리입니다.

모든 것을 버전 관리하에 두겠다고 말하고 싶습니다. 모든 것이 작동하면 대부분의 SCM 시스템에서 서버에 많은 디스크 공간이 필요하지 않은 태그에 복사 할 수 있습니다.

초기 함정이있는 한 크게 걱정할 필요는 없습니다. 서버에 모든 것을 커밋하고 정확하지 않으면 나중에 섞어서 여분의 것을 삭제할 수 있습니다. 내가 커밋하지 않는 유일한 것은 소스에서 빌드 된 아티팩트입니다. 즉, Java 코드 파일은 버전 제어에 속하지만 컴파일 된 클래스 또는 "소스에서 빌드"바이너리의 전체 ISO / DVD는 아닙니다.

생산에 대한 개발은 쉬우 며, 모든 주요 이정표에서 지점을 만듭니다. 버전 관리 시스템의 디렉토리 레이아웃은 일반적으로 다음과 같습니다.

/ trunk / project / branches / project / version1 / branches / project / version2 / branches / project / version3

제품 버전 2에서 버그를 찾아 해당 분기로 이동하여 수정 한 후 버전 2.1을 릴리스한다고 가정 해 보겠습니다. 새 버전 4의 / trunk / project 폴더에서 작업하는 동안 모든 기능이 앞뒤로 병합됩니다.

SCM 쿨 에이드 술꾼이 당신을 속이게하지 마십시오. 인기있는 버전 관리 시스템, 즉 Subversion과 Git 사이에는 기능상의 차이가 거의 없습니다. 팀에게 가장 중요한 것은 해당 서버가 기존 도구와 얼마나 잘 통합되는지입니다. 나는 WYSIWYG를 좋아하지 않지만 일식 PHP 또는 서버와 호환되는 다른 IDE를 갖는 것이 좋습니다.

저는 개발자이며 전에 IT 관리자로 일한 적이 있습니다.

특정 질문에 대답하려면

1) 예, 모든 것을 버전 화하십시오.

2) 사람들이 배울 수있는 더미 버전 제어 저장소와 더미 프로젝트를 설정하도록 제안하십시오.

3) 생산에 들어가는 버전에 태그를 지정하십시오. 시련까지도. 그러면 누군가 실행중인 특정 버전을 항상 확인할 수 있습니다.

질문 CVS에 태그를 추가 한 것을 확인했습니다.

TortoiseSVN과 결합하여 Subversion을 진지하게 살펴보고 사용하기가 매우 좋습니다. TortoiseCVS도 있습니다.

버전 관리에 대한 사내 자습서를 실행하는 것이 좋습니다. 개발자 / 디자이너가 이전에이 문제를 겪지 않은 것에 대해 놀랐습니다. 거북이는 매우 사용자 친화적입니다.

웹 인터페이스 중 하나를 cvs 또는 subversion에 설치하는 것이 좋습니다.

CVS보다 Subversion을 제안하는 이유는 CVS가 매우 좋지만 심각한 디자인 및 구현 문제가 있기 때문입니다. 나를위한 가장 큰 장점은 다음과 같습니다. 1) 디렉토리 버전을 지정할 수 없습니다. 2) 많은 것들이 기본적으로 텍스트 인 것처럼 이진 파일 처리가 너무 좋지 않습니다. 3) 원자 커밋이 없습니다. 4) 코드 저장소에서 수동으로 제거 해야하는 잠금 파일을 엉망으로 만들고 떠난 것을 자주 기억합니다. rm 잠금 파일 이후로이 작업을 수행 할 때 손상의 여지가있었습니다. 5) SSL 지원 및 사용자 / 암호 관리

Subversion은 기본적으로 이러한 모든 문제를 해결할 수 있습니다. 또한 외부와 같은 많은 고급 기능이 있습니다 (실제로 사용합니다). 또한 사용자 / 그룹을 활성 디렉토리에 링크하여 유용 할 수 있습니다. 당시에는 사용할 수 없었던 CVS를 사용했습니다. 지금 확인하지 않았을 수도 있습니다.

아마도 svn을 사용하는 데있어 가장 큰 차이점은 태그를 만들지 않는다는 것입니다. 대신 프로젝트 디렉토리가 태그 폴더에 복사되고 이름이 지정된 사본으로 표시되는 것을 만듭니다. 설명서를 살펴보면 무슨 뜻인지 알 수 있습니다. 이상하게 보이지만 익숙해집니다.

이 웹 사이트는 약간의 이점이 있습니다 (보증 할 수는 없지만) : PHP 웹 사이트를위한 모듈 식 svn 저장소 설정 http://www.howtoforge.com/set-up-a-modular-svn-repository-for -php- 웹 사이트

그것은 - 위의 표시 지혜의 정도에 큰 관하여 이다 현명한 - 버전 컨트롤의 출시 모니터링 시스템의 출시 같다. 내 고객은 "무엇을 모니터링해야합니까?"라고 말하고 확실한 대답은 "모두 모니터링"입니다. 그러나 이것은 반가운 소식이 아닙니다. 350 개의 시스템이 있으며 각 시스템에는 20-30 개의 시스템 변수와 사용 특정 변수가 있으며 모두 유용하게 모니터링 할 수 있습니다. 하지만 내 사람은 한 명 뿐이며 2 주일 안에 결과를보고 싶습니다.

따라서 최선의 방법은 모든 것을 버전 관리하는 것입니다. 그러나 이것이 처음에는 실용적이지 않다면, 제어력이 부족하여 지금까지 대부분의 문제를 일으킨 것들을 제어하는 ​​것으로 시작하십시오 .

응용 프로그램 코드로 인해 대부분의 중단이 발생한 경우이를 제어하여 시작하십시오. 계획되지 않은 CSS 패치가 대부분인 경우이를 제어하십시오. 등등.

이렇게하면 최고의 투자 수익률을 얻을 수있을뿐만 아니라 향후 버전 제어 사용을 확장해야하는 확실한 이유를 얻을 수 있습니다. "응용 프로그램 코드에 버전 제어를 추가 한 이후 30 분 동안 계획되지 않은 중단 한 달에 11 개에서 2 개로 줄었습니다.이 두 가지는 정적 HTML 변경으로 인한 것이기 때문에 다음 버전을 제어 할 계획입니다. "

단계적 롤아웃은 조직 내부의 숙련 된 사용자에게도 제공됩니다. 그렇습니다. 6 명의 앱 개발자 모두에게 시스템 사용법을 가르쳐 주어야했지만 배웠습니다. 이제 CSS 팀에 시스템을 배포 할 차례가되었으므로 3 개월 전보다 6 명의 사내 전문가가 더 있습니다. 지금까지 개종 한 사람들도있을 것입니다. 피해를 입은 변경 사항을 즉시 철회 할 수있는 능력으로 엉덩이를 구한 개발자는 CSS 팀의 가장 좋은 전도자 일 것입니다.

편집 1 :이 경로로 가기로 결정하면 칩으로 저렴한 백스톱은 적어도 생산 상자에 트립 와이어 를 추가 하는 것입니다. 그런 식으로, 만약 상황이 브레이크하지만 VCS는 그것이 현재 빠르게 무엇을 식별 할 수 있습니다에 대한 책임이 아무것도 없다고 말합니다 있다 모두 수정 속도 및 버전 제어를위한 당신의 다음 후보를 제안하는 변경을.

모든 버전 관리. 버전 제어하에 HTML 파일이 있고 제어되지 않는 CSS의 변경으로 인해 사이트가 완전히 망가 져서 쉽게 되돌릴 수 없다는 점은 없습니다.

함정 : 필자는 상당히 제한된 버전 제어 사용 중에 개인적으로 어떤 것도 발견하지 못했습니다.

배포 : 현재 직장과 가정에서 모두 Windows 상자에서 호스팅되는 하위 버전을 사용합니다. Windows 만 가능하므로 사용할 수 있습니다. 그렇지 않으면 다른 OS처럼 쉽게 할 수 있습니다. 기술을 사용하지 않는 사용자를위한 열쇠는 가져 오기, 내보내기, 커밋, diff 등을 처리 할 수있는 간단한 GUI 기반 도구를 제공하는 것입니다. 사용할 도구는 사용되는 OS 및 VCS 시스템에 따라 다릅니다.

사용 : 코드를 변경할 때 자주 테스트하고 커밋합니다. 이렇게하면 나사를 조일 때 필요한만큼 뒤로 돌아갈 수 있습니다. 또한 다양한 수정본을 비교하고 코드의 일부를 복사하면 이전 버전으로 되돌려 코드의 다른 부분에서 일부 내용을 수정해야하기 때문에 모든 변경 사항을 잃을 필요가 없습니다.

추가 이점 : VPN 또는 보안 연결을 통해 소스 리포지토리에 액세스 할 수 있으므로 사용자는 집이나 다른 곳에서 작업 할 수 있습니다. 예를 들어, 집에서 아이디어를 얻어서 작업 코드를 편집 한 다음 생각을 잃기 전에 편집 할 수 있습니다.

모든 것을 버전.

배포는 이러한 각 사이트에 대해 "사용자 정의"해야하는 금액에 따라 다릅니다. 구성 파일을 제외하고 동일하다면 코드 사본을 확인하고 약간만 변경하면됩니다. 필요에 따라 각 클라이언트에 대해 버전 제어의 업데이트 명령을 실행하십시오.

"고객 사이트에 직접 체크 아웃"배포 모델을 사용하는 경우 사람들이 http://example.com/을 탐색 할 수 없도록 서버에서 버전 제어 디렉토리에 대한 액세스를 제외해야합니다 . git / 및 내부를 들여다보십시오. 또한, 나는 것이 확실히 사이트 업데이트가 엉망이 이동하지 않도록하기 위해 각 클라이언트에 대한 테스트 및 생산 가상 호스트가 있습니다. 특히 개별 클라이언트의 파일을 사용자 지정으로 변경하는 경우 변경 사항을 적용하기 전에 충돌을 처리해야합니다. 이 경우 테스트 가상 호스트를 체크 아웃 / 업데이트하고 모든 것이 올바르게 작동하면 테스트 가상 호스트를 프로덕션 가상 호스트에 복사합니다.

사람들이 무엇을 버전 화해야하는지에 대해 말하고 있습니다.

Subversion을 사용하기로 결정한 경우 Bitnami Trac 스택을 사용해 보는 것이 좋습니다. http://bitnami.org/stack/trac

Subversion 설정을 단순화하고 변경 및 버그를 추적 할 수있는 티켓 시스템 (이 단계에서 사용하도록 선택하거나 사용하지 않을 수 있음)과 개발자가 사용하는 방법을 문서화하는 데 사용할 수있는 Wiki가 제공됩니다. 시스템.

모든 Windows 개발자에게 TortoiseSVN을 제공하십시오. 모든 svn 명령 줄 기본 사항을 모든 사람에게 가르쳐주십시오.

하루가 끝날 무렵,이 도구는 개발자에게 심어 주어야하는 사고 방식보다 덜 중요합니다. 그들이 곧 버전 제어가 좋은 일이기 때문에 그들이 일을 잃는 것을 막고 막 다른 곳으로 돌아가서 알려진 좋은 상태로 돌아 가지 못하게 할 수 있기를 바랍니다. 이점은 (약간) 오버 헤드보다 큽니다.