우리는 기존 코드베이스로 상당히 큰 웹 사이트에서 작업하기 시작한 그룹입니다. 테스트와 프로덕션 서버가 있습니다.
우리의 아이디어는 많은 개발자들이 액세스 할 수있는 테스트 저장소를 갖는 것입니다. 그리고 소수만이 밀 수있는 복된 저장소. 축복받은 저장소는 항상 안정적이며 최신 프로덕션 버전을 나타냅니다.
파일을 프로덕션으로 전송하는 프로세스를 자동화하려면 어떻게해야합니까? 프로덕션 파일을 버전 관리 상태로 두는 것이 좋지 않습니까? 그런 식으로 축복받은 저장소로 나아가는 것은 배포를 의미합니다. 그러나 병합 충돌이 발생하면 어떻게됩니까? 프로덕션 서버가 해결 될 때까지 중단됩니까?
답변:
간단히 말해서 :
푸시 프로세스 자체는 완전 자동이어야합니다. 사용자 정의 스크립트가 있는지 또는 단순히 "축복 된"저장소에서 프로덕션 환경으로 끌어 오십시오. 그건 너에게 달렸어. 자동화 된 프로세스를 신뢰할 수있게 만들 수 있기 때문에 (자동으로 파일을 업로드하는 것이 아니라) 자동화 된 것이 있어야합니다.
그러나 푸시 프로세스는 수동으로 트리거해야합니다. 업데이트를 푸시하고 확신이 들면 릴리스 후보로 태그를 지정하고 테스트 환경으로 가져옵니다 (가능한 한 프로덕션 환경과 유사). RC가 테스트되면 푸시를 시작할 수 있습니다.
오늘날, 인간 테스터가 할 수있는 것 외에는 아무것도 줄 수 없습니다.
피드백 루프가 비교적 크다는 점에서 약간 느리게 들립니다. 그러나 적절한 테스트를 위해서는 고정 된 스냅 샷을 찍어 24-48 시간 (또는 프로젝트 규모에 따라 더 많은 시간) 동안 검사해야합니다. 그 반대의 경우 시나리오를 추진 한 직후에 많은 버그를 발견하고 새로운 버그를 도입하는 몇 가지 빠른 수정 사항으로 패치하려고합니다.
알려지지 않은 버그 (알 수없는 심각도)가있는 것보다 알려진 버그 (허용 가능한 심각도)가있는 릴리스를 만드는 것이 좋습니다.
사용중인 플랫폼에 따라 프로덕션 릴리스를 자동화하는 데 사용할 수있는 많은 도구가 있습니다. 나는 .NET 상점에서 일하고 있으므로 NAnt를 사용하고 있습니다 (현재 MSBuild가 더 나은 옵션이지만). Java에는 Ant와 다른 것들이 있습니다. 루비에는 레이크와 같은 것들이 있습니다. 그런 다음 릴리스 관리에도 사용할 수있는 TeamCity 및 Hudson과 같은 지속적인 통합 플랫폼이 있습니다.
나는 별도의 소스 제어 저장소에 직접 코드를 가지고 있다는 것을 보거나들은 적이 없지만 확실히 작동 할 수 있습니다. back2dos가 말했듯이, 열쇠는 자동화하는 것입니다. 소스 제어, 빌드 및 스테이징 환경 테스트에서 체크 아웃하도록 설계된 빌드 스크립트가 있습니다. 그런 다음 준비 작업 방식이 마음에 들면 QA에서 Prod로 스크립트가 복사됩니다.
권장 사항은 도구를보고 도구를 선택한 다음 선택한 도구와 잘 작동하는 프로세스를 설계하는 것입니다. 바퀴를 너무 많이 발명하려고하지 마십시오. 이것은 매우 해결 된 문제입니다.