저는 Capistrano를 처음 접했고, 제 프로젝트를 위해 Capistrano 구성을 관리하는 것이 가장 좋은 방법인지 궁금합니다.Capistrano 구성 관리에 대한 우수 사례?
특히 config/deploy.rb
은 내 프로젝트의 소스 제어와 관련하여 어디에서 살고 있습니까? 특정 구성 정보없이 파일 템플리트를 저장해야합니까? 또는이 구성이 팀간에 공유되는 자체 저장소에 있어야합니까?
저는 Capistrano를 처음 접했고, 제 프로젝트를 위해 Capistrano 구성을 관리하는 것이 가장 좋은 방법인지 궁금합니다.Capistrano 구성 관리에 대한 우수 사례?
특히 config/deploy.rb
은 내 프로젝트의 소스 제어와 관련하여 어디에서 살고 있습니까? 특정 구성 정보없이 파일 템플리트를 저장해야합니까? 또는이 구성이 팀간에 공유되는 자체 저장소에 있어야합니까?
나는 카피스트라노를 점점 더 사용하기 시작했을 때 이것에 대해 궁금해했다. 우리 대부분은 런타임 구성 정보를 기능 코드과 별도로 추적하는 것이 합리적이라고 생각하십니까? 따라서 배포 구성에 대해서도 같은 결과가 발생하지 않아야합니까?
./deploy/
폴더를 SCM 하위 모듈로 만들 수 있습니다. 당신은 이 작업 복사본에 Capfile을 생성하는 레이크 작업을 수행 할 수 있습니다. 따라서 앱 외부에서 최종 암호와 물건을 유지할 수 있습니다 ...이 경우 사용할 수있는 보석이있을 수도 있습니다.
그러나 나는 다른 방법을 선택했다 :
내가 카피 스트라 노 변수의 대부분은 set(:deploy_to) {"#{base_dir}/#{environment}/#{application}"}
같은 패턴을 따를 수있는 걸쳐 약 10 개의 다른 응용 프로그램을 가지고 있고, 마찬가지로 소스 코드 저장소 경로에 대한.
모두 개별 응용 프로그램의 배포에 대한 지식을 제거하고 대신 하나의 별도의 일반적인 "배포"프로젝트에 포함 시켰습니다. 지금은 그 프로젝트를 확인하고 갈 수
cap [some application] [environment] [deploy task]
내가 사방 Capfiles 주위에 확산보다 더 많은 관심이 패턴/분리를 선호합니다.
아주 좋은 질문입니다.
나는 또한 모든 deploy.rb 관련 내용을 배포 프로젝트에 넣었으며 응용 프로그램 프로젝트에서 symlink로 연결했습니다. 당시에는 Webistrano가 자체 조리법 풀을 유지할 수있는 것처럼 보였기 때문에이를 보았습니다. 프로젝트가 더 이상 유지되지 않는 것처럼 보이기 때문에 나는 위의 접근 방식을 사용했다.