Composer의 개발 / 생산 스위치를 사용할 때 올바르게 배포하는 방법은 무엇입니까?

Composer에는 개발 중에 만 여러 종속성을로드 할 수있는 옵션이 있으므로 프로덕션 환경 (라이브 서버)에 도구가 설치되지 않습니다. 이것은 이론적으로 테스트, 가짜 데이터 도구, 디버거 등과 같이 개발에만 의미가있는 스크립트에 매우 유용합니다.

가는 방법 require-dev은 개발자가 필요로하는 도구 로 추가 블록 을 추가하는 것입니다 .

"require-dev": {
    "codeception/codeception": "1.6.0.3"
}

그런 다음 이론적으로 이러한 종속성을로드합니다.

composer install --dev

문제 및 질문 :

작곡가의 동작을 변경 install하고 update극적으로 2013 년, require-dev-dependencies가 기본으로 설치되어있다 (!)에있어서 A composer.json 만들어 주시기 require-dev블록과 수행 composer install재현.

가장 널리 배포되는 방법은 작곡가를 밀어내는 것입니다. (현재 작곡가 설정을 보유한) lock을 만든 다음 composer install프로덕션 서버에서 작업 을 수행 하면 개발 항목도 설치됩니다.

-dev 의존성 을 설치 하지 않고 이것을 배포하는 올바른 방법은 무엇입니까 ?

_{참고 : 이상한 Composer 배포를 명확히하기 위해 여기에 표준 Q / A를 만들려고합니다. 이 질문을 자유롭게 편집하십시오.}

왜

오늘날 Composer가 --dev기본적으로 (설치 및 업데이트시) 플래그를 사용하는 이유는 IMHO 입니다. Composer는 주로 시나리오에서 원하는 동작으로 실행됩니다.

기본 Composer 워크 플로우는 다음과 같습니다.

• composer.phar install --dev, json 및 lock 파일이 VCS에 커밋 된 새 프로젝트가 시작 됩니다.
• 다른 개발자는 프로젝트 작업을 시작 : VCS의 체크 아웃하고 composer.phar install --dev.
• 개발자는 dependancies : composer.phar require <package>를 추가 --dev합니다. require-dev섹션 에서 패키지를 원하면 추가 하십시오 (및 커밋).
• (체크 아웃 등) : 다른 사람을 따라 간다 composer.phar install --dev.
• 개발자는 최신 버전의 종속성 composer.phar update --dev <package>(및 커밋)을 원합니다 .
• (체크 아웃 등) : 다른 사람을 따라 간다 composer.phar install --dev.
• 프로젝트가 배포되었습니다 : composer.phar install --no-dev

보시다시피 --dev깃발은--no-dev , 특히 프로젝트에서 작업하는 개발자 수가 증가 할 때 플래그가 플래그 .

프로덕션 배포

"dev"의존성을 설치하지 않고 이것을 배포하는 올바른 방법은 무엇입니까?

음 composer.json과 composer.lock파일은 VCS에 커밋되어야합니다. composer.lock사용해야하는 패키지 버전에 대한 중요한 정보가 포함되어 있으므로 생략하지 마십시오 .

프로덕션 배포를 수행 할 때 --no-dev플래그를 Composer에 전달할 수 있습니다 .

composer.phar install --no-dev

이 composer.lock파일에는 dev-packages에 대한 정보가 포함될 수 있습니다. 이것은 중요하지 않습니다. 이 --no-dev플래그는 해당 개발 패키지가 설치되지 않았는지 확인합니다.

"프로덕션 배포"라고 말하면 프로덕션에서 사용되는 것을 목표로하는 배포를 의미합니다. composer.phar install프로덕션 서버에서 수행해야하는지 또는 검토 할 수있는 준비 서버에서 수행 해야하는지에 대해서는 논쟁하지 않습니다 . 이것이이 답변의 범위가 아닙니다. 나는 단지 방법을 지적하고있다.composer.phar install "dev"의존성을 설치하지 않고 .

주제를 벗어

--optimize-autoloader플래그는 생산에 바람직 할 수있다 (이것은 응용 프로그램에서 자동 로딩 속도가 빨라집니다 클래스 맵을 생성) :

composer.phar install --no-dev --optimize-autoloader

또는 자동 배포가 완료된 경우 :

composer.phar install --no-ansi --no-dev --no-interaction --no-plugins --no-progress --no-scripts --no-suggest --optimize-autoloader

당신의 코드베이스가 지원하는 경우에, 당신은 밖으로 교환 수 --optimize-autoloader에 대해 --classmap-authoritative. 더 많은 정보는 여기에

실제로 프로덕션 서버에 종속성을 설치하는 것이 좋습니다.

권장 사항은 배포 컴퓨터에서 코드를 체크 아웃하고 필요에 따라 종속성을 설치 한 다음 (코드가 프로덕션 환경으로 갈 경우 개발자 종속성을 설치하지 않는 것을 포함) 모든 파일을 대상 컴퓨터로 옮기는 것이 좋습니다.

왜?

• 공유 호스팅에서 명령 행에 도달하지 못할 수 있습니다.
• 하더라도 PHP는 명령, 메모리 또는 네트워크 액세스 측면에서 제한 될 수 있습니다.
• 저장소 CLI 도구 (Git, Svn)가 설치되지 않았을 수 있습니다. 잠금 파일이 해당 커밋을 ZIP으로 다운로드하는 대신 특정 커밋을 체크 아웃하는 종속성을 기록한 경우 실패합니다 (--prefer-source를 사용했거나 Composer가 그 버전을 얻는 다른 방법은 없습니다)
• 프로덕션 머신이 소규모 테스트 서버와 비슷한 경우 (Amazon EC2 마이크로 인스턴스 생각) 실행할 메모리가 충분하지 않을 수 있습니다. composer install
• 작곡가가 문제를 일으키지 않으면 서 작곡가 설치 단계에서 임의의 종속성을로드 할 수 없기 때문에 부분적으로 깨진 프로덕션 웹 사이트로 끝나는 것에 대해 어떻게 생각하십니까

간단히 말해 : 제어 할 수있는 환경에서 Composer를 사용하십시오. Composer를 작동하는 데 필요한 모든 것이 이미 있으므로 개발 시스템이 적합합니다.

-dev 의존성을 설치하지 않고 이것을 배포하는 올바른 방법은 무엇입니까?

사용할 명령은

composer install --no-dev

이것은 실제 환경에서 개발 요구 사항이 잘못 사용되었는지 확인하기 위해 마지막 검사를 수행해야하는 개발 서버 또는 프로덕션 서버 자체 또는 모든 환경에서 작동합니다.

이 명령은 composer.lock 파일에 선언 된 dev 요구 사항을 설치하거나 적극적으로 제거하지 않습니다.

프로덕션 서버에 개발 소프트웨어 구성 요소를 배포하는 데 신경 쓰지 않으면 실행 composer install은 동일한 작업을 수행하지만 이동하는 바이트 수를 늘리고 더 큰 자동 로더 선언을 만듭니다.

이제 require-dev기본적으로 활성화되어 지역 발전을 위해 당신이 할 수 composer install와 composer update포함하지 않는 --dev옵션을 선택합니다.

프로덕션에 배포하려면 composer.lock에서 제공 한 패키지가 없는지 확인해야합니다 require-dev.

당신은 이것을 할 수 있습니다

composer update --no-dev

로컬에서 테스트 한 후에는에 --no-dev모든 것을 프로덕션에 배포하고에 따라 설치할 수 있습니다 composer.lock. --no-dev여기서 다시 옵션 이 필요합니다 . 그렇지 않으면 작곡가에 "잠금 파일에 require-dev 정보가 없습니다"라고 표시 됩니다.

composer install --no-dev

참고 : 개발자와 프로덕션간에 차이가 생길 수있는 모든 것에주의하십시오! 개발자 도구를 포함시키는 것이 큰 오버 헤드가 아니기 때문에 일반적으로 가능한 경우 require-dev를 피하려고합니다.

프로덕션 서버에서는로 이름 vendor을 바꾸고 vendor-<datetime>배포하는 동안 두 개의 공급 업체 디렉토리가 있습니다.

HTTP 쿠키는 시스템이 새로운 공급 업체를 선택하게합니다 autoload.php 테스트 후 모든 미래 요청에 대해 이전 공급 업체 디렉토리를 비활성화하기 위해 완전히 원자 / 순간 전환을 수행 한 다음 며칠 후에 이전 디렉토리를 삭제합니다.

이것은 아파치 / PHP에서 사용중인 파일 시스템 캐시로 인한 문제를 피하고 활성 PHP 코드가 이전 공급 업체 디렉토리를 계속 사용할 수있게합니다.

그것에 대해 추천하는 다른 답변에도 불구하고, 나는 개인적으로 달려 composer install , 서버에서 . 이는 내 준비 영역 (노트북의 VM)에서 rsync보다 빠르기 때문입니다.

사용 --no-dev --no-scripts --optimize-autoloader합니다. 각 문서에 대한 문서를 읽고 이것이 환경에 적합한 지 확인해야합니다.

프로세스를 자동화하는 것이 좋습니다.

git 저장소에 composer.lock 파일을 추가하고 composer.phar install --no-dev 를 사용하십시오 릴리스 할 때 . 그러나 dev 시스템에서는 composer 명령을 걱정하지 않고 사용할 수 있습니다. 이는 프로덕션으로 이동하지 않습니다. 프로덕션은 잠금 파일에서 해당 종속성을 기반으로합니다.

테스트가 통과되면 서버에서이 특정 버전 또는 레이블을 체크 아웃하고 앱을 교체하기 전에 모든 테스트를 실행하십시오.

테스트가 개발자 종속성에 의존하는 경우, composer에 테스트 범위 종속성이 없기 때문에 개발에 의존하지 않는 솔루션 ( composer.phar install )으로 공급 업체 라이브러리를 제거하고 composer.phar install- -no-dev 다시 캐시 된 종속성을 사용하므로 더 빠릅니다. 그러나 다른 빌드 도구에서 범위 개념을 알고 있다면 그것은 해킹입니다.

이것을 자동화하고 나머지를 잊고 맥주를 마시십시오 :-)

추신 : @Sven 주석 아래에서와 같이 composer.lock 파일을 체크 아웃하지 않는 것이 좋습니다. 이는 composer 설치가 composer 업데이트로 작동하기 때문입니다.

http://deployer.org/를 사용 하여 자동화를 수행 할 수 있습니다. 간단한 도구입니다.