한동안 애플리케이션을 개발한 다음 애플리케이션을 Gemfile
,
Gemfile.lock
과 함께 체크인하세요. 이때 저장소는 마지막으로 애플리케이션이
동작했을 때 사용한 gem의 정확한 버전의 기록을 가지고 있습니다.
Gemfile
에(버전의 엄격함의 정도에 차이도 있겠지만)
3개의 gem만 있다고 하더라도 애플리케이션은 수십 개의 gem을 의존하고 의존하는
모든 암시적인 gem의 요구사항을 고려해야 합니다.
Gemfile.lock
이 애플리케이션의 코드와 gem이 제대로 동작했다는
확신이 있는 최후의 순간을 하나의 묶음으로 만든다는 점은 중요합니다.
Gemfile
에 gem의 정확한 버전을 지정한다 하여도 같은 수준의 보장은 안 됩니다.
왜냐하면 gem은 보통 의존성을 범위로 지정하기 때문입니다.
이후 같은 기기에서 bundle install
을 실행하면, 모든 필요한 의존성을 만족하므로
번들러가 설치 과정을 생략하는 것을 볼 수 있습니다.
.bundle
디렉터리와 그 안의 어떤 내용도 체크인하지 말아 주세요. 그 파일들을
각각의 기기의 특성에 따라 달라지고 bundle install
명령어 간의 영속적인 설치
옵션을 사용합니다.
bundle pack
명령어를 실행했고 git의 gem이 아니라면, 번들러에서 요구된 gem은
모두 vendor/cache
에 다운로드 됩니다. 모든 필요한 gem이 폴더에 들어있고
버전 관리에 체크인 되어있다면 인터넷이나 루비젬스 서버에 접속하지 않고 실행할 수 있습니다.
이것은 생략가능한 과정이며, 버전 관리 저장소의 크기를 늘리므로 추천하지
않습니다.
동료 개발자가 코드를 채크아웃하거나 당신이 다른 기기에 체크아웃하면 개발할 때 애플리케이션에서
사용했던 모든 gem의 정확한 버전도(Gemfile.lock
안에) 함께 옵니다.
**거기서** bundle install
을 실행하면 번들러는 Gemfile.lock
을 찾고
의존성 해결과정을 생략합니다. 대신에 원래 기기에서 사용했던 것과 같은 모든 gem을 설치합니다.
다시 말하자면 어떤 버전의 의존성을 설치해야 하는지 고민할 필요가 없습니다. 아까 보았던
예제에서 rack-cache
가 rack >= 0.4
에 의존성이 있다고 정의되어도
rack 1.2.1
에서 움직인다고 확신할 수 있습니다. Rack 팀이 rack 1.2.2
를
릴리스하더라도 번들러는 항상 동작이 보장되는 1.2.1
을 설치합니다. 이것은
개발자로 하여금 많은 관리부담을 덜게 합니다. 왜냐하면, 모든 기기에서 똑같은 gem을 사용하기
때문입니다.