Magento2-로컬 / 스테이징 / 제작 배포 및 gitignore

이것은 질문이 아닌 일종의 토론 일 수 있습니다.

Magento2 및 로컬 > 스테이징 > 프로덕션 환경에서 어떤 배치 정책을 따르는 지 알고 싶습니다.

일부 시도 후에 우리는 최선의 (또는 적어도 가장 확실한) 접근 방식 을 git의 공급 업체 폴더를 포함하는이 gitignore 파일이라고 결정했습니다 .

.DS_Store
/.buildpath
/.cache
/.metadata
/.project
/.settings
atlassian*
/nbproject
/sitemap
/sitemap.xml
/.idea
/.gitattributes
/app/config_sandbox
/app/etc/config.php
/app/etc/env.php
/app/code/Magento/TestModule*
/lib/internal/flex/uploader/.actionScriptProperties
/lib/internal/flex/uploader/.flexProperties
/lib/internal/flex/uploader/.project
/lib/internal/flex/uploader/.settings
/lib/internal/flex/varien/.actionScriptProperties
/lib/internal/flex/varien/.flexLibProperties
/lib/internal/flex/varien/.project
/lib/internal/flex/varien/.settings
/node_modules
/.grunt
/pestle.phar
/pub/media/*.*
!/pub/media/.htaccess
/pub/media/catalog/*
!/pub/media/catalog/.htaccess
/pub/media/customer/*
!/pub/media/customer/.htaccess
/pub/media/downloadable/*
!/pub/media/downloadable/.htaccess
/pub/media/import/*
!/pub/media/import/.htaccess
/pub/media/theme/*
/pub/media/theme_customization/*
!/pub/media/theme_customization/.htaccess
/pub/media/wysiwyg/*
!/pub/media/wysiwyg/.htaccess
/pub/media/tmp/*
!/pub/media/tmp/.htaccess
/pub/media/captcha/*
/pub/static/***
!/pub/static/.htaccess

/var/*
!/var/.htaccess

.unison*
/sync.sh

따라서 우리 는 로컬 환경에서만 작곡가 를 실행 합니다. 새로운 확장 프로그램이나 소프트웨어 업그레이드가 로컬에서 테스트되고 검증되고 커밋되었습니다. 우리는 아마도 git에 app / etc / config.php 파일 을 포함시킬 것입니다. 하지만 파일을 실행할 때 다시 작성됩니다 setup:upgrade.

벤더를 포함 한다는 것은 리포지토리 크기가 권장되는 것보다 클 것이라는 것을 의미하지만 코드를 배포 할 때 이런 방식으로 시퀀스를 실행합니다

bin/magento setup:upgrade
bin/magento setup:di:compile (optional)
bin/magento setup:static-content:deploy

관련 정보 : http://www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

왜 우리가 컴파일 명령을 선택적인 Magento 2-setup : di : compile 로 선택하는지보십시오 .

최신 정보

사실 우리는 공개 된 Magento 2 프로젝트에서 코드 변경 사항을 배포 할 때 약간의 문제가 있습니다

로컬 및 스테이징에서 변경 사항이 작동합니다 (개발자 및 프로덕션 ... 개발자 환경에서 개념적으로 해당 환경을 구성하더라도). 우리가 올바른 전략을 따르는 지 확신하지 못합니다. 적절한 명령 순서가 무엇인지, 해당 명령의 순서와 관련이 있는지 확인하고 싶습니다.

사실, 프로젝트에서 아무것도 변경하지 않으면 매일 Magento 2 프로덕션 모드의 유틸리티에 대해 확신이 덜합니다. 내 마음을 바꿀 수 있습니까?

사실, 프로젝트에서 아무것도 변경하지 않으면 매일 Magento 2 프로덕션 모드의 유틸리티에 대해 확신이 덜합니다. 내 마음을 바꿀 수 있습니까?

내가 당신을 올바르게 이해하고 있는지 확실하지 않지만, 그것이 생산 모드의 목적입니다 : 당신 이 아무것도 바꾸지 않는 생산 시스템 (코드 현명한). 다음 배포까지입니다.

모든 전처리로 인해 Magento 1보다 Magento 2에 덜 적합하다는 Git 기반 배포가 있습니다. 빌드 및 배포가 더 복잡하고 자동화 된 빌드 프로세스를 해결할 방법이 없습니다.

내가 추천하는 것 :

• 반복 가능한 배포가 있어야 합니다. 즉 , 생성 된 파일을 포함하여 준비중인 프로덕션에서 정확히 동일한 코드가 생성되도록해야합니다 .

• 이를 위해서는 빌드와 배포를 분리 하고 빌드 프로세스에서 다음을 수행하십시오.

  • composer install( vendor대신 리포지토리에 추가 하는 것도 가능하지만 배포 중에 서버에서 작곡가를 실행하지 않으려면 빌드 단계에서 수행하고 리포지토리에만 보관 composer.lock하십시오)

  • 코드 생성 (YMMV) :

    bin/magento setup:di:compile
    bin/magento setup:static-content:deploy
    

  • 아카이브 (작성 빌드 유물 을 제외한 전체 젠토 디렉토리)를 media하고 var있지만, 포함 vendor, pub, var/generated와 var/di. 시작 젠토-2.2 , var/generated그리고 var/di로 이동 generated/code하고 generated/metadata쉽게의 나머지 부분을 분리 할 수있는, var배포 무시해야한다.

• 배치에서 빌드 아티팩트를 대상 서버에 복사하고 새 디렉토리로 추출한 후 다음을 수행하십시오.

  • 그것으로 지속적인 디렉토리를 링크 ( media, var/session, var/log, ...)
  • 유지 관리 모드 활성화
  • 문서 루트 전환 (일반적으로 docroot는 마지막 릴리스에 대한 심볼릭 링크이며 새 릴리스로 변경)
  • 캐시 플러시
  • 운영 setup:upgrade
  • 유지 관리 모드 비활성화

• 이 배포 프로세스는 Capistrano와 유사하지만 PHP에서 Deployer를 사용 하여 쉽게 구현할 수 있습니다 . 배포자 기반의 Magento 2에 대한 전체 배포 솔루션은 https://github.com/mwr/magedeploy2(netz98 덕분에)에서 찾을 수 있으며 여기에 사용되는 또 다른 솔루션이 있습니다. https://github.com/staempfli / magento2-deployment-tool

• 유지 app/etc/config.php저장소에가 활성화 장애인 모듈을 추적하는 것이 좋다.

이것은 단계별 지침이 아니지만 현재 프로세스에 대한보다 강력한 대안에 대한 개요를 제공해야합니다. 전체 솔루션이 어떻게 보이는지 링크 된 도구를 살펴보십시오.

내 생각에 Magento 2.2를 기다리거나 비슷한 접근법을 시도하십시오.

Magento 2.2는 빌드 서버와 프로덕션 서버를 분리하여 파이프 라인 배포 를 도입했습니다 .

공식 문서는 다음과 같습니다. http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

또한 현재 Ansible을 사용하여 구성 템플릿 및 다중 환경 설정으로 자동화 된 배포를 관리하고 있습니다.