composer.lock을 버전 관리에 전념해야합니까?

composer.lock리포지토리가있는 응용 프로그램에서 사용 하는 것과 약간 혼동됩니다 .

나는 많은 사람들이 우리가 .gitignore composer.lock창고에서 나와서 는 안된다고 말하는 것을 보았다 .

개발 환경에서 라이브러리를 업데이트하면 새 라이브러리를 갖게 composer.lock되지만 프로덕션 환경으로 업데이트 할 수 없습니다.

이 파일에서 충돌이 발생하지 않습니까?

라이브러리를 업데이트하면 잠금 파일도 커밋하려고합니다. 기본적으로 프로젝트가 사용중인 특정 버전의 라이브러리에 잠겨 있음을 나타냅니다.

변경 사항을 커밋하고 누군가 코드를 가져와 종속성을 업데이트하면 잠금 파일을 수정하지 않아야합니다. 수정 된 경우 새로운 버전의 것을 의미합니다.

리포지토리에 저장하면 각 개발자가 동일한 버전을 사용하고 있습니다.

응용 프로그램 / 프로젝트 : 확실히 그렇습니다.

작곡가 설명서 (강조)이에 상태 :

응용 프로그램의 composer.lock (composer.json과 함께)을 버전 제어로 확약하십시오.

@meza가 말했듯이 : 잠금 파일을 커밋하여 공동 작업자가 동일한 버전의 작업을 수행하고 "하지만 내 컴퓨터에서 작동했습니다"와 같은 문구가 표시되지 않도록해야합니다. ;-)

도서관의 경우 : 아마도 아닙니다.

이 문제에 대한 작곡가 문서 노트 :

참고 : 라이브러리의 경우 반드시 잠금 파일 (...)을 커밋하지 않는 것이 좋습니다.

그리고 여기에 있습니다 :

라이브러리의 경우 원하는 경우 composer.lock 파일을 커밋 할 수 있습니다. 이를 통해 팀은 항상 동일한 종속성 버전에 대해 테스트 할 수 있습니다. 그러나이 잠금 파일은 종속 된 다른 프로젝트에는 영향을 미치지 않습니다. 메인 프로젝트에만 영향을 미칩니다.

라이브러리의 경우 @Josh Johnson의 답변에 동의합니다.

몇 가지 프로젝트에 대해 두 가지 방법을 모두 수행 한 후에 composer.lock는 프로젝트의 일부로 커밋해서는 안됩니다.

composer.lock프로젝트의 일부가 아닌 빌드 메타 데이터입니다. 종속성 상태는 마지막 개발자가 임의로 업데이트하지 않고 잠금 파일을 커밋하지 않고 수동 또는 자동 빌드 프로세스의 일부로 버전을 관리하는 방법을 통해 제어되어야합니다.

작성기 업데이트 사이의 종속성 변경에 대해 걱정이된다면 버전 관리 체계에 대한 확신이 부족합니다. 버전 (1.0, 1.1, 1.2 등)은 변경할 수 없으며 초기 기능 개발 이외의 "dev-"및 "X. *"와일드 카드를 피해야합니다.

종속성 파일이 이제 암시 적으로 정의되었으므로 잠금 파일 커밋은 종속성 관리 시스템에 대한 회귀입니다.

또한 프로젝트를 다시 빌드하거나 각 환경, 특히 자극에 대한 종속성을 다시 확보 할 필요가 없습니다. 결과물 (tar, zip, phar, 디렉토리 등)은 변경할 수 없으며 변경없이 환경을 통해 승격되어야합니다.

1. 프로덕션에서 직접 종속성을 업데이트해서는 안됩니다.
2. composer.lock 파일의 버전을 제어해야 합니다.
3. 실제 종속성을 버전 제어해서는 안됩니다.

1. 이것이 코드 안정성에 어떤 영향을 줄지 모르기 때문에 Production에 직접 의존성을 업데이트해서는 안됩니다 . 새로운 의존성으로 인해 버그가 발생할 수 있으며, 코드가 자신의 코드에 영향을 미치는 방식을 변경하거나 다른 의존성과 호환되지 않을 수 있습니다. 적절한 QA 및 회귀 테스트에 따라 dev 환경 에서이 작업을 수행해야합니다. .

2. composer.lock 파일의 버전을 제어해야 합니다. 이는 코드의 현재 상태를 복제 할 수 있도록하는 종속성 및 종속성의 종속성에 대한 정보를 저장하기 때문입니다. 모든 테스트 및 개발이 특정 코드에 대해 수행되었으므로 이는 중요합니다. 실제 코드 버전에 신경 쓰지 않는 것은 코드 변경 사항을 응용 프로그램에 업로드하고 테스트하지 않는 것과 비슷합니다. 의존성 버전을 업그레이드하는 경우, 이는 기꺼이 행동해야하며 모든 것이 여전히 작동하도록주의를 기울여야합니다. 한 두 시간의 가동 시간을 이전 릴리스 버전으로 되 돌리면 많은 비용이들 수 있습니다.

composer.lock 이 필요하지 않다는 주장 중 하나는 composer.json 파일에 필요한 정확한 버전을 설정할 수 있다는 것 입니다.이 방법으로 누군가가 실행될 때마다 composer install동일한 버전을 설치합니다. 암호. 종속성은 자체 종속성이 있으며 구성이 서브 버전 또는 전체 버전으로 업데이트 할 수있는 형식으로 지정 될 수 있기 때문에 이는 사실이 아닙니다.

이 방법 당신은 당신의 Laravel 4.1.31 지정할 경우에도 그 composer.json 의에서, Laravel을 composer.json의 심포니의 이벤트 디스패처에 필요한 자신의 종속성이있을 수 있습니다 파일 : 2. *를. 이런 종류의 구성을 사용하면 Symfony 이벤트 디스패처 2.4.1을 사용하여 Laravel 4.1.31로 끝날 수 있으며 팀의 다른 사람이 이벤트 디스패처 2.6.5를 사용하여 Laravel 4.1.31을 가질 수 있습니다. 작곡가 설치를 마지막으로 실행 한 시간이었습니다.

따라서 버전 시스템에 composer.lock 파일이 있으면이 하위 종속성의 정확한 버전이 저장되므로 귀하와 팀원이 작곡가 설치를 수행 할 때 (이것이 작곡가 에 따라 종속성을 설치하는 방식입니다 . lock ) 둘 다 동일한 버전을 얻습니다.

업데이트하려면 어떻게합니까? 그런 다음 dev 환경에서 :을 실행 composer update하면 새로운 composer.lock 파일 (새로운 것이있는 경우)이 생성되고 테스트 한 후에 QA 테스트 및 회귀 테스트를 수행합니다. 안전하게 업그레이드 할 수 있으므로 다른 사람이 새 composer.lock 을 다운로드하도록 푸시 할 수 있습니다 .

3. 실제 의존성을 버전 제어해서는 안됩니다 . 으로 composer.lock 당신은 의존성의 정확한 버전을 설치하고 당신이 그들을 저지 할 필요가 없습니다 것입니다. 의존성을 업데이트하지 않을 때 repo 10000 파일을 repo 10000 파일에 추가하는 이유는 무엇입니까? 이 중 하나를 변경해야하는 경우이를 분기하여 변경해야합니다. 또한 빌드 또는 릴리스 할 때마다 실제 종속성을 가져와야하는 것에 대해 걱정하는 경우 작곡가는이 문제, 캐시, zip 파일 등을 완화하는 다른 방법을 갖습니다.

그런 다음 composer.json프로젝트에 커밋하고 팀의 다른 모든 사람이 composer install을 실행하여 프로젝트 종속성을 설치할 수 있습니다.

잠금 파일의 요점은 다시 설치 될 수 있도록 설치된 정확한 버전을 기록하는 것입니다. 즉, 버전 사양이 1. *이고 동료가 1.2.4를 설치하는 composer 업데이트를 실행 한 다음 composer.lock 파일을 커밋하면 composer 설치시 1.2.4도 얻게됩니다. 1.3.0이 릴리스 된 경우 이를 통해 프로젝트에서 작업하는 모든 사람이 동일한 정확한 버전을 가질 수 있습니다.

즉, 작곡가 설치가 마지막으로 완료된 이후에 커밋 된 것이 있으면 잠금 파일없이 새 타사 코드가 다운 됩니다.

다시 말하지만, 코드가 깨질 우려가 있습니다. Composer를 composer.lock 파일을 중심으로 생각하는 것이 중요한 이유 중 하나입니다.

출처 : 작곡가 : 잠금 파일에 관한 것 입니다.

응용 프로그램의 composer.lock (composer.json과 함께)을 버전 제어로 확약하십시오. install 명령은 잠금 파일이 존재하는지 확인하고 존재하는 경우 composer.json의 설명에 관계없이 지정된 버전을 다운로드하기 때문에 중요합니다. 즉, 프로젝트를 설정하는 사람은 모두 동일한 버전의 종속성을 다운로드해야합니다. CI 서버, 프로덕션 시스템, 팀의 다른 개발자, 모든 사람 및 모든 사람이 동일한 종속성에서 실행되므로 배포의 일부에만 영향을주는 버그의 가능성이 줄어 듭니다. 단독으로 개발하더라도 프로젝트를 다시 설치할 때 6 개월 안에 종속성이 이후 많은 새 버전을 릴리스하더라도 설치된 종속성이 여전히 작동한다고 확신 할 수 있습니다.

출처 : 작곡가-기본 사용법 .

코드 손상이 우려되는 경우 composer.lock모든 프로젝트 공동 작업자가 동일한 버전의 코드를 사용하도록 버전 제어 시스템에 커밋해야 합니다. 잠금 파일이 없으면 매번 새로운 타사 코드가 풀다운됩니다.

설치시 종속성을 업데이트해야하는 라이브러리 인 메타 앱 ( Zend Framework 2 Skeleton App 과 같은)은 예외입니다 . 따라서 목표는 개발을 시작할 때마다 최신 종속성을 얻는 것입니다.

^{출처 : 작곡가 : 잠금 파일에 관한 모든 것}

composer 업데이트와 composer 설치의 차이점은 무엇입니까?를 참조하십시오 .

이에 대한 정확한 답은 없습니다.

일반적으로 composer는 빌드 시스템이 수행하려는 작업을 수행하지 않아야하며 composer.lock을 VCS에 두지 않아야합니다. 작곡가가 이상하게 거꾸로 가지고있을 수 있습니다. 생산이 아닌 최종 사용자는 잠금 파일을 사용해서는 안됩니다. 일반적으로 빌드 시스템은 매번 빈 디렉토리가 아닌 스냅 샷, 재사용 가능한 디렉토리 등을 유지합니다. 사람들은 composer에서 lib를 체크 아웃하여 lib 가로 드하는 종속성을 테스트하기 위해 해당 lib가 잠금을 사용하기를 원할 수 있습니다.

반면에 버전 관리의 부담을 크게 증가시키는 것은 종속성이 엄격하게 고정되므로 모든 라이브러리의 여러 버전을 거의 확실하게 원할 것입니다. 모든 라이브러리의 버전이 약간 다를 경우 라이브러리 버전을 여러 개 지원해야하며 필요한 종속성의 크기를 신속하게 확인할 수 있으므로 라이브러리를 유지하는 것이 좋습니다.

이것을 보드에 가져 가면 라이브러리 또는 자신의 작업 디렉토리에 유용한 잠금 파일을 찾지 못합니다. 그것은 단지 내 빌드 / 테스트 플랫폼에서만 사용되며 외부 수집 자산은 요청시에만 업데이트하여 테스트, 빌드 및 배포를 위해 반복 가능한 빌드를 제공합니다. VCS에 유지할 수는 있지만 항상 소스 트리와 함께 유지되는 것은 아니지만 빌드 트리는 VCS 구조의 다른 곳에 있거나 다른 시스템에 의해 다른 곳에서 관리됩니다. VCS에 저장된 경우 소스 트리와 동일한 리포지토리에 보관할지 여부에 대해서는 논란의 여지가 있습니다. 그렇지 않으면 모든 풀이 대량의 빌드 자산을 가져올 수 있기 때문입니다. 나는 프로덕션 / 민감한 자격 증명과 부풀림을 제외하고는 잘 정리 된 저장소에 모든 것을 갖는 것을 좋아합니다.

SVN은 전체 저장소를 강제로 가져 오지 않기 때문에 git보다 더 잘 수행 할 수 있습니다 (실제로 git에는 엄격하게 필요하지는 않지만 지원은 제한적이며 일반적으로 사용되지 않음). 간단한 빌드 리포지토리는 일반적으로 빌드 트리를 병합 / 내 보낸 오버레이 브랜치입니다. 일부 사람들은 외부 리소스를 소스 트리에 결합하거나 외부, 빌드 및 소스 트리를 분리합니다. 일반적으로 빌드 캐싱과 반복 가능한 빌드의 두 가지 목적을 제공하지만 때로는 최소한 어느 정도 분리하여 유지하면 신선 / 빈 빌드와 여러 빌드를 쉽게 수행 할 수 있습니다.

여기에는 여러 가지 전략이 있으며 소스 트리에 외부 소스를 유지하지 않는 한 소스 목록을 유지하는 데 특히 효과적인 전략은 없습니다.

또한 파일에 해시와 같은 것들이 있습니다. 두 사람이 패키지를 업데이트 할 때 어떻게 병합됩니까? 그것만으로도 이것이 잘못 해석되었다고 생각하게해야합니다.

사람들이 잠금 파일을 제시하는 주장은 문제에 대해 매우 구체적이고 제한적인 관점을 취하는 경우입니다. 반복 가능한 빌드와 일관된 빌드를 원하십니까? VCS에 공급 업체 폴더를 포함하십시오. 그런 다음 자산 가져 오기 속도를 높이고 빌드 중에 손상된 외부 리소스에 의존 할 필요가 없습니다. 내가 만든 빌드 및 배포 파이프 라인은 절대적으로 필요한 경우가 아니면 외부 액세스가 필요하지 않습니다. 외부 리소스를 업데이트해야하는 경우 한 번만 가능합니다. 작곡가가 달성하려고 시도하는 것은 분산 시스템에서 의미가 있습니다. 일반 충돌이있는 라이브러리 업데이트와 업데이트 속도가 가장 느린 패키지의 라이브러리 업데이트에 대한 라이브러리 종속성 지옥으로 끝나기 때문에 언급되지 않은 경우를 제외하고는 의미가 없습니다.

또한 나는 격렬하게 업데이트합니다. 개발할 때마다 모든 것을 업데이트하고 테스트합니다. 의미있는 버전 변경이 발생할 수있는 매우 작은 창이 있습니다. 실제로 시맨틱 한 버전 관리가 유지되는 경우에도 작곡가를위한 것이므로 호환성 문제 나 파손이 많지 않다고 생각할 수 있습니다.

composer.json에는 필요한 패키지와 해당 버전을 넣습니다. 거기에서 버전을 잠글 수 있습니다. 그러나 해당 패키지에는 composer.json에 의해 잠기지 않는 동적 버전과의 종속성이 있습니다 (단, 버전 잠금을 원할 경우 사용자가 직접 넣을 수없는 이유는 모르겠습니다). 자물쇠없이 다른 것을 얻습니다. 당신은 그것에 대해 크게 신경 쓰지 않을 수도 있고 신경 쓸 수도 있습니다. 걱정해야합니까? 어쩌면 적어도 어느 정도 상황과 잠재적 영향을 인식 할 수있을 정도로 약간 적지 만 항상 DRY를 먼저 실행하고 업데이트 된 내용을 수정해야 할 시간이 있다면 문제가되지 않을 수 있습니다.

번거로운 작곡가는 때때로 존재하지 않고 작곡가 잠금 파일을 만들 수있는 번거 로움을 피하려고합니다. VCS에 별도의 참여 여부에 관계없이 빌드 및 소스 자산과 관련하여 수행해야 할 것과 수행하지 말아야 할 일을 사용자에게 말할 권리가 없습니다. "작곡가의 말"은 권위가 아니며, 그들은 당신의 상급 책임자가 아니며,이 주제에 대해 어떤 우월성을 부여하지도 않습니다. 오직 당신 만이 당신의 실제 상황과 그에 가장 적합한 것을 알고 있습니다. 그러나 그들은 어떤 방식으로 작동하는지 이해하지 못하는 사용자를 위해 기본 행동 과정을 조언 할 수 있습니다. 사물이 작동하는 방식을 알고 요구 사항을 올바르게 수행 할 수있는 것을 대체합니다. 궁극적으로, 그 질문에 대한 그들의 대답은 최선의 추측입니다. 작곡가를 만드는 사람들은 작곡가를 어디에 보관해야하는지 알 수 없습니다. 그들의 유일한 책임은 그것이 무엇이고 무엇을 하는지를 알려주는 것입니다. 그 외에는 자신에게 가장 적합한 것을 결정해야합니다.

잠금 파일을 유지하는 것은 작곡가가 잠금을 사용하는지 JSON을 사용하는지에 대해 매우 비밀을 유지하고 항상 함께 사용하는 것이 좋지 않기 때문에 유용성에 문제가됩니다. 설치를 실행하면 잠금 파일 만 사용되므로 composer.json에 무언가를 추가하면 잠금 파일이 아니기 때문에 설치되지 않습니다. json / lock 파일과 관련하여 실제로 작업이 수행하는 작업과 수행중인 작업은 직관적이지 않으며 때로는 의미가없는 것처럼 보입니다 (도움말은 설치가 패키지 이름을 사용하지만 사용하려고하면 아니오라고 말합니다) ).

잠금을 업데이트하거나 기본적으로 json에서 변경 사항을 적용하려면 업데이트를 사용해야하며 모든 것을 업데이트하지 않을 수도 있습니다. 설치해야 할 항목을 선택하기 위해 잠금이 우선합니다. 잠금 파일이 있으면 사용 된 파일입니다. 업데이트를 다소 제한 할 수 있지만 시스템은 여전히 ​​엉망입니다.

RAM을 업데이트하려면 시간이 오래 걸립니다. 한동안 손대지 않은 프로젝트를 가져 와서 버전이 올라간 버전에서 찾은 것으로 생각합니다. 시간이 지남에 따라 더 많은 것을 보았을 것입니다.

그것은 당신이 합성 할 것으로 예상 할 수없는 비밀 복합 명령을 가질 때 매우 비열합니다. 기본적으로 composer remove 명령은 예를 들어 composer update 및 composer remove에 매핑되는 것으로 나타납니다.

실제로 물어봐야 할 질문은 소스 트리에 잠금을 유지해야하는지 또는 다른 방식으로 고정해야하는지 여부가 아니라 실제로 수행하는 작업을 묻는 것이 아니라 스스로 결정할 수 있다는 것입니다. 언제 어디서 유지해야하는지

강력한 외부 의존성 지속성 전략을 보유한 경우 잠금 기능을 보유하는 것이 정보를 추적하고 (원점) 업데이트하는 데 유용한 정보를 추적하지만 정보를 업데이트하지 않는 경우 매우 편리합니다. 그리고 거기도 없습니다. 소스 트리를 오염시키는 필수 옵션으로 목을 강요 할 때는 유용하지 않습니다. 사람들이 composer.json을 많이 변경 한 레거시 코드베이스에서 사람들이 작곡가를 사용하려고 할 때 실제로 적용되지 않았고 손상 된 것을 발견하는 것은 매우 일반적인 일입니다. composer.lock, desync 문제가 없습니다.

그렇습니다.

로컬에 설치된 composer가 composer.json보다 composer.lock 파일을 우선적으로 사용하기 때문입니다.

vcs에서 잠금 파일을 사용할 수없는 경우 작곡가는 최신 종속성 또는 버전을 설치하기 위해 composer.json 파일을 가리 킵니다.

composer.lock 파일은 종속성을보다 깊이있게 유지합니다. 즉, 소프트웨어에 포함 된 패키지 버전의 실제 커밋을 가리 키므로 종속성을보다 세밀하게 처리하는 가장 중요한 파일 중 하나입니다.