$ echo ".bundle" >> .gitignore
$ git add Gemfile Gemfile.lock .gitignore
$ git commit -m "Add Bundler support"

$ bundle install --deployment

카피스트라노로 하는 자동 배포

require 'bundler/capistrano'

require 'bundler/vlad'

task "vlad:deploy" => %w[
  vlad:update vlad:bundle:install vlad:start_app vlad:cleanup
]

$ bundle exec rake db:setup

$ heroku config:add BUNDLE_WITHOUT="test development" --app app_name

배포 시나리오에서 유닉스 사용자는 시스템 영역에 gem을 설치할 권한이 없을 것입니다. 배포하는 사용자에게 권한이 있(거나 sudo를 사용한)다 하더라도 애플리케이션을 실행하는 사용자에게는 권한이 없을 수도 있습니다. 예를 들어 패신저는 루비 서브 프로세스를 제한된 사용자인 nobody로 실행합니다. 배포 환경에서는 환경을 격리하는 데 보다 힘을 씁니다.(어떤 서드파티 의존성이 바뀌었을 때 배포 중에 bundle install이 느려진다고 해도 말이죠.)

결과적으로 번들러를 --deployment 플래그와 함께 사용하면 배포환경에서 번들러를 사용하는 최선의 사례을 캡슐화합니다. 이 사례들은 번들러의 개발 기간 동안 받은 중요한 피드백뿐만 아니라, 버그 리포트를 기반으로 합니다. 버그 리포트의 대부분은 가장 적합한 배포를 위한 번들러를 구성하는 방법에 대한 오해를 반영하고 있습니다. --deployment 플래그는 기본적으로 다음을 추가합니다.

카피스트라노를 사용하시고 계신다면 vendor/bundle을 shared/vendor_bundle의 심볼릭 링크로 만드실 수 있습니다. 이렇게 하면 번들러는 배포판 사이에 설치된 gem을 공유해 (변경되지 않았다면 배포 과정을 단축하면서) 다른 애플리케이션과 격리되는 장점은 유지 할 수 있습니다.

기본적으로 번들 디렉터리는 vendor/bundle입니다. 그리고 배포 프로세스의 일부로 번들을 설치하면 애플리케이션을 체크아웃한 같은 유닉스 사용자들도 애플리케이션에서 필요한 서드파티 코드들이 설치되어 있는 것을 확인 할 수 있습니다. 이 말은 페신저(또는 유니콘)가 애플리케이션을 볼 수 있다면, 의존성도 볼 수 있다는 이야기입니다.

--deployment 플래그는 실제로 프로덕션에 코드를 반영하기 전에 (개발과 스테이징 환경에서) 테스트가 끝난 최신의 Gemfile.lock을 필요로 합니다. 배포하기 전에 bundle check를 실행해 Gemfile.lock이 최신 상태인지 확인할 수 있습니다. 마지막으로 Gemfile을 변경한 이후 bundle install을 실행하고 성공적으로 애플리케이션을 부트(하거나, 테스트를 실행)했다면 항상 최신 상태임을 주의하세요.