공유하기

코드를 버전 관리하기

한동안 애플리케이션을 개발한 다음 애플리케이션을 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-cacherack >= 0.4에 의존성이 있다고 정의되어도 rack 1.2.1에서 움직인다고 확신할 수 있습니다. Rack 팀이 rack 1.2.2를 릴리스하더라도 번들러는 항상 동작이 보장되는 1.2.1을 설치합니다. 이것은 개발자로 하여금 많은 관리부담을 덜게 합니다. 왜냐하면, 모든 기기에서 똑같은 gem을 사용하기 때문입니다.

Fork me on GitHub
Docs: Previous Version (v1.10) Current Version (v1.11)