Commerce 버전 업그레이드

Staging 및 Production 환경에서만 서비스를 설치하거나 업데이트하려면 Adobe Commerce 지원 티켓을 제출하세요.

티켓에서 필요한 서비스 변경 사항을 지정하고 업데이트된 .magento.app.yaml 및 .magento/services.yaml 파일을 포함한 다음 대상 PHP 버전을 확인합니다.

PHP 버전, Composer 업데이트, 확장, 환경 설정 등은 셀프서비스 변경 사항입니다. Adobe에서 PHP 버전 호환성을 위해 New Relic 에이전트를 업데이트해야 할 수 있습니다. 응용 프로그램 구성​에서 PHP 설정을 참조하십시오.

Adobe의 두 가지 프로세스를 통해 업그레이드 일정을 확인: 요청한 날짜와 시간을 먼저 확인한 다음, 지원 팀에서 최종 확인을 위해 인프라 팀에 제출합니다.

생산 변경(Pro 전용)에는 주말을 제외하고 영업일 기준으로 최소 2일 이상의 통지가 필요합니다. 예를 들어 클라우드 인프라 팀은 이전 수요일까지 월요일 업그레이드를 승인해야 합니다. 최대 수요 동안 추가 리드 타임을 예상합니다. 지연을 방지하려면 초기 요청에 적어도 창 48시간 전에 응답합니다. 업그레이드는 최종 확인을 받을 때까지 예약된 것으로 간주되지 않습니다.

프로덕션에서 예약하기 전에 스테이징 또는 통합 환경에서 업그레이드의 유효성을 검사하십시오.

서드파티 모듈, 사용자 지정 코드 또는 종속성 호환성으로 인해 발생한 문제는 서비스 업그레이드 후 재배포 중에 종종 발생합니다. 여러 서비스 업그레이드를 한 번에 하나씩 검증하려면 Valkey 또는 Redis, RabbitMQ, OpenSearch, MariaDB를 차례로 주문해야 합니다. 이 시퀀스는 필수 시퀀스가 아닙니다. 데이터베이스 업그레이드는 운영에 가장 큰 영향을 미치므로 가장 주의해야 합니다.

시간은 환경 및 관련 서비스에 따라 다르므로 Adobe은 프로덕션 유지 관리 기간의 정확한 기간을 사전에 보장하지 않습니다. 프로덕션 창을 계획할 때 스테이징 업그레이드가 실제 예상으로 소요되는 시간을 사용합니다.

Adobe 응용 프로그램 버전이 변경되지 않더라도 변경 사항이 적용되도록 Adobe Commerce이 서비스 업그레이드를 완료한 후 환경을 다시 배포​합니다.

업그레이드에 OpenSearch가 포함된 경우 전체 색인 재지정도 계획합니다. Adobe은 서비스 업그레이드에 대해 무중단 다운타임을 보장할 수 없으므로 사이트를 다시 열기 전에 재배포하고, 필요한 경우 색인을 재지정하고, 상점 및 관리자의 유효성을 확인할 수 있는 유지 관리 기간을 계획하십시오.

config 섹션에 다음 allow-plugins을(를) 추가합니다.

"config": {
   "allow-plugins": {
      "dealerdirect/phpcodesniffer-composer-installer": true,
      "laminas/laminas-dependency-plugin": true,
      "magento/*": true
   }
},

require 섹션에 다음 플러그인을 추가하십시오.

"require": {
    "magento/composer-root-update-plugin": "^2.0.3"
},

extra:component_paths 섹션에 다음 구성 요소를 추가합니다.

"extra": {
   "component_paths": {
      "tinymce/tinymce": "lib/web/tiny_mce_5"
   },
},

파일을 저장합니다. 아직 분기에 변경 사항을 커밋하거나 푸시하지 마십시오.

업그레이드 프로세스를 계속합니다.

원격 데이터베이스의 로컬 백업을 만듭니다.

magento-cloud db:dump

코드 및 미디어를 백업합니다.

php bin/magento setup:backup --code [--media]

소스 제어에 이미 많은 정적 파일이 있는 경우 [--media]을(를) 생략할 수도 있습니다.

SSH를 사용하여 원격 환경에 로그인합니다.

데이터베이스 덤프를 만듭니다. DB 덤프의 대상 디렉터리를 선택하려면 --dump-directory 옵션을 사용합니다.

vendor/bin/ece-tools db-dump

덤프 작업에서 원격 프로젝트 디렉터리에 dump-<timestamp>.sql.gz 보관 파일을 만듭니다. 데이터베이스 백업을 참조하십시오.

로컬 워크스테이션에서 프로젝트 디렉터리로 변경합니다.

대상 업그레이드 버전에 대해 버전 제약 조건을 설정하십시오. 이 단계는 대상 버전이 기존 제약 조건을 벗어나는 경우에만 필요합니다.

composer require-commerce "magento/magento-cloud-metapackage":">=CURRENT_VERSION <NEXT_VERSION" --no-update

composer.json 파일을 핵심 Commerce 업그레이드 버전으로 업데이트하십시오.

composer require-commerce magento/product-enterprise-edition 2.4.8 --no-update

B2B를 사용하는 경우 composer.json 파일을 Commerce용 지원되는 버전​(으)로 업데이트하십시오.

composer require-commerce magento/extension-b2b 1.5.2 --no-update

프로젝트 종속성을 업데이트합니다.

composer update

현재 적용된 패치를 검토합니다.

• m2-hotfixes 디렉터리에 패치가 설치되어 있는 경우 Adobe Commerce 지원 티켓을 제출하고 Adobe Commerce 지원 팀과 함께 새 버전에 적용할 수 있는 패치를 확인하십시오. m2-hotfixes 디렉터리에서 적용할 수 없는 패치를 제거합니다.

• .magento.env.yaml 파일에 [품질 패치]가 적용된 경우 새 버전에 계속 적용할 수 있는지 확인하십시오. .magento.env.yaml 파일의 QUALITY_PATCHES 섹션에서 적용할 수 없는 패치를 제거합니다.

메서드 1: 품질 패치 릴리스 정보에서 해당 버전을 확인

메서드 2: 사용 가능한 패치와 상태 보기

메서드 3: 패치 검색

코드 변경 사항을 추가, 커밋 및 푸시합니다.

git add -A

git commit -m "Upgrade"

git push origin <branch-name>

Composer가 기본 패키지를 마샬링하는 방식 때문에 변경된 모든 파일을 소스 제어에 추가하려면 git add -A이(가) 필요합니다. 기본 패키지(magento/magento2-base 및 magento/magento2-ee-base)의 composer install 및 composer update 파일을 모두 패키지 루트로 마샬링합니다.

작성기가 마샬링하는 파일은 새 버전의 Adobe Commerce에 속하므로 동일한 파일의 오래된 버전을 덮어씁니다. 현재 Adobe Commerce에서는 마샬링을 사용할 수 없으므로 마샬링된 파일을 소스 제어에 추가해야 합니다.

업그레이드를 완료하려면 배포를 기다리십시오.

SSH를 사용하여 로그인하고 버전을 확인하여 통합, 스테이징 또는 프로덕션 환경에서 업그레이드를 확인합니다.

php bin/magento --version

로컬 워크스테이션에 분기를 만듭니다.

필요에 따라 확장을 비활성화합니다.

사용 가능한 경우 확장 업그레이드를 다운로드합니다.

타사 설명서에 따라 업그레이드를 설치합니다.

확장을 활성화하고 테스트합니다.

코드 변경 사항을 원격에 추가, 커밋 및 푸시합니다.

을 푸시하고 통합 환경에서 테스트합니다.

사전 프로덕션 환경에서 테스트하려면 스테이징 환경으로 푸시합니다.

로컬 워크스테이션에서 프로젝트 디렉터리로 변경합니다.

SSH를 사용하여 원격 환경에 로그인합니다.

magento-cloud ssh

./app/var/report/<error number> 파일을 엽니다.

로그를 검사하고 문제의 원인을 확인합니다.

코드 변경 사항을 추가, 커밋 및 푸시합니다.

git add -A && git commit -m "Fixed deployment failure" && git push origin <branch-name>