웹 사이트 버전 관리 : 개발 / 생산 프론트 엔드 파일


9

웹 사이트 프로젝트를 버전 관리하는 더 좋은 방법을 생각하고 있습니다. 저는 프론트 엔드 개발자 일 뿐이므로 VCS에 대한 깊은 지식이 없습니다.

워크 플로우가 변화하고 있으며 과거 버전 관리 습관이 더 이상 사용되지 않습니다. 주요 문제는 각 웹 사이트마다 2 개의 프런트 엔드 파일 배열이 있다는 것입니다.

개발 환경 (파일, 압축되지 않은 js, 이미지 등) "굴곡 된"빌드 환경 (사람이 압축하고 읽을 수없는 모든 것).

그러나 소스 파일이있는 웹 사이트는 판매 할 수 없습니다. 글쎄, 그것은 기분이 좋지 않습니다.

2 개의 repos가있는 솔루션이 있습니다 : 하나의 빌드, 하나의 dev, gulp는 dev 파일을 빌드 디렉토리로 보냅니다. 그러나 소규모 회사에서는 유지 관리가 번거롭지 않다고 생각합니다. 그것은 많은 저장소를 생성하며 사람들은 여러 저장소로 관리해야하며 때로는 하나의 svn 저장소로도 문제가 발생합니다.

따라서 소스 파일과 prod 파일을 같은 svn에 1 개의 리포지토리가있는 솔루션도 있습니다. 그러나 웹 사이트가 로컬 개발자 서버에서 프로덕션 서버로 이동할 때 소스 파일을 제거해야합니다 (따라서 위치, 개발자 또는 프로덕션에 따라 단일 저장소에 다른 파일이 있습니다.). 내가 들었던 것에서 그것은 좋지 않다

버전 제어 시스템과 관련하여 펄프 프론트 엔드 워크 플로우를 관리하는 올바른 방법은 무엇입니까?

답변:


13

소스 제어의 기본 규칙 중 하나는 수동으로 작성된 아티팩트 를 리포지토리 (원본 소스 파일) 에만 넣어야한다는 것입니다. "컴파일"또는 "생성"될 수있는 모든 항목은 중복을 생성하기 때문에 저장할 필요가 없습니다. . 하나는 (선택 사항) 단계는 그들을 완전 자동하지 않거나 빌드 단계를 재현 할 때, 목적을 캐싱에 대한 출력 속도가 느린 재생하는 경우, REPO에 (때로는라고도 유물을) 중간 출력 / 빌드 프로세스의 일부를 저장 .

따라서 개발자 소스 파일에서 프로덕션 파일을 생성하는 완전히 자동화 된 프로세스가있는 경우 프로덕션 파일을 작성하기위한 스크립트와 함께 dev 파일 만 소스 제어에 넣으면됩니다. 그렇지 않은 경우 그러한 프로세스를 설정하십시오. 프로덕션 파일이 소스에서 생성 된 후 수동으로 장난하지 않아야합니다. VCS에서 "직접"배치하려는 경우, dev 소스 파일을 소스 제어에서 가져오고 "gulpification"을 수행하고 결과 파일을 한 단계에서 프로덕션으로 전송하는 배치 스크립트가 있는지 확인하십시오.

물론 소스 제어를 "가난한 백업"또는 프로덕션 파일의 캐시로 사용하려는 경우이 목적으로 두 번째 리포지토리를 설정하고 생성 후 프로덕션 파일 구조의 사본을 넣을 수 있습니다. 이 리포지토리는 개발에 사용되지 않으며 설정 후에는 수동으로 유지 관리 할 필요가 없습니다. 따라서이 "prod repo"로 백업을 수행하는 데 필요한 수동 단계가 없는지 확인하십시오 . 백업을 자동으로 만드는 배치 스크립트에 필요한 단계를 포함하십시오. 배치 후 프로덕션에 대한 수동 변경을 금지 할 수없는 경우 별도의 백업 스크립트 추가를 고려하십시오. 이렇게하면 리소스가 제한되어 있어도 프로세스를 유지 관리 할 수 ​​있습니다.

그리고 네, 이것은 완전히 분리 된 두 번째 저장소 여야합니다. 왜냐하면 그것은 완전히 다른 목적과 다른 라이프 사이클을 가지고 있기 때문입니다. 다른 프로세스 인 소스 제어가 아닌 백업에만 사용합니다.


사이트가 프로덕션 환경으로 갈 때 프로덕션 서버에서 사이트를 빌드해야한다는 의미입니까? 아니면 단지 (다음 versionned되지 않음) 빌드 호스트
안토닌 Cezard

@topleft : "제작 서버"에서? 소스 코드가 리포지토리에있을 필요는 없으며 소스 제어 및 프로덕션 서버의 파일 시스템에 액세스 할 수있는 모든 곳에서 소스 코드를 빌드 할 수 있습니다. 따라서 원하는 경우 dev 시스템, decicated 빌드 시스템 또는 prod 시스템에서 직접 사용할 수 있습니다. 그러나 귀하의 의견을 작성한 후 추가 된 단락도 참조하십시오.
Doc Brown

3
당신의 말이 혼란 스럽다. "아티팩트"는 종종 입력이 아닌 컴파일러 또는 생성기 의 출력 을 나타냅니다 .
데니스

항상 정확한 것은 아닙니다. 부트 스트랩 된 컴파일러의 경우 생성 된 파일을 VCS에 두어야 할 수도 있습니다. 전형적인 예는 Ocaml의 바이트 코드 boot/ocamlc또는 GCC melt/generated/*.cc
MELT

1
@Daenyth : AFAIK 단어 유물의 수단은 주로 수동으로 소프트웨어 개발에서 생산 된 부품. 컴파일러가 생성하는 것은 간접적으로 수동 프로그래밍 작업의 결과 이기 때문에 일부 상황에서는 사람들이 "빌드 아티팩트"를 말하는 것이 맞습니다 .
Doc Brown
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.