Adobe Commerce을 위한 코드 관리 우수 사례

이 항목은 릴리스 관리, 코드 복잡성 및 종속성 관리를 고려하여 Git 또는 작성기를 사용하여 사용자 지정 코드를 배포할지 여부를 결정하는 데 도움이 되도록 설계되었습니다.

NOTE
이러한 Best Practice는 마이그레이션 및 구현에 가장 적합하며 단일 모듈 개발에는 더 적습니다.

영향을 받는 제품 및 버전

지원되는 모든 버전:

  • 클라우드 인프라의 Adobe Commerce
  • Adobe Commerce 온-프레미스

GRA(전역 참조 아키텍처)과(와) 단일 인스턴스 설치를 모두 다룹니다.

정의

  • GRA(전역 참조 아키텍처): 화이트 레이블 아키텍처 또는 일반 코드 베이스라고도 합니다. 다중 인스턴스 설정을 위한 모듈 배포 아키텍처입니다.
  • 다중 인스턴스 설정: 동일한 클라이언트가 별도의 지역 또는 브랜드에 대해 별도의 Adobe Commerce 설치를 사용합니다. 각 설치는 고유 모듈을 공유하며
  • 단일 인스턴스 설치: Adobe Commerce 설치가 하나만 있습니다. 소스 코드의 여러 복사본이 서로 다른 테스트 환경에 대해 존재할 수 있지만 프로덕션 코드의 버전은 하나만 있습니다.

Git 또는 Composer 사용 시기

주로 Git을 통해 관리되는 코드
주로 작성기를 통해 관리되는 코드
단일 인스턴스 설정에 을 사용해야 하는 경우
  • 단일 인스턴스 설정을 위한 코드 관리에 대한 표준 접근 방식
  • 향후 코드 베이스가 다중 브랜드 GRA의 일부가 아닌 경우
  • 모든 브랜드가 단일 인스턴스에서 웹 사이트로 실행되는 경우
  • 나중에 코드 베이스가 다중 인스턴스 설정의 일부가 될 수 있거나 될 때
다중 인스턴스 설정에 을 사용해야 하는 경우
  • 거의 모든 모듈이 상호 연결된 경우(권장되지 않음)
  • 작성기에 익숙하지 않은 팀이 코드를 유지 관리하는 경우
  • 다중 인스턴스 설정을 위한 코드 관리에 대한 표준 접근 방식
  • Adobe이 코드 베이스를 유지하거나 유지 관리 팀이 작성기에 익숙한 경우

기능 매트릭스

기능
Git
작성기
주 코드 저장소
모든 코드는 단일 또는 몇 개의 Git 저장소에 있습니다
모든 코드는 Composer 저장소의 패키지에 있습니다
각 단일 Composer 패키지는 Git 저장소로 표시됩니다
코드 위치
개발은 app/ 디렉터리에서 수행됩니다.
개발은 vendor/ 디렉터리에서 수행됩니다.
핵심 업그레이드 관리
Adobe Commerce core가 Composer를 사용하여 설치 및 업그레이드되면 결과는 Git에 커밋됩니다.
Adobe Commerce core는 Composer를 사용하여 설치 및 업그레이드됩니다. 결과는 Git에 커밋됩니다.
타사 모듈 관리
타사 모듈은 마켓플레이스 또는 packagist.org을 통해 설치된 경우 vendor/에 설치됩니다. 그렇지 않으면 app/에 설치됩니다.
모든 타사 모듈은 vendor/ 디렉터리에 설치됩니다.
릴리스
해제는 git mergegit pull 또는 git checkout 명령으로 특징지어집니다.
해제는 composer updategit pull 또는 git checkout 명령으로 특징지어집니다.
Git 저장소 수
몇 개
많음
개발 복잡성
단순
복합
끌어오기 요청 복잡성
단순
복합
코드 검토 복잡성
단순
단순
개발/QA/UAT 환경 업데이트 복잡성
단순
복합
GRA 지원
예 아이콘
예 아이콘
모듈은 자동으로 외부 라이브러리를 설치할 수 있습니다.
아이콘 없음
예 아이콘
GRA 구성의 유연성
아이콘 없음
예 아이콘
모듈 종속성 관리
예 아이콘 은(는) module.xml을(를) 통해서만 사용할 수 있으며 기능이 제한됩니다.
예 아이콘 composer.json을(를) 통한 전체 종속성 관리
모듈 버전 관리
예 아이콘 버전을 정의할 수 있지만 특정 버전을 설치할 수는 없습니다
예 아이콘 전체 버전 지원
유료 서비스 필요
Git 저장소
Git 저장소, 비공개 패키지 목록(연간 ± €600)
Jira와 Bitbucket 통합 가능
예 아이콘
예 아이콘
코드 변경 사항이 즉시 설치 가능
예 아이콘
예 아이콘

피해야 할 솔루션

  1. 모듈에 대해 작성기와 app/code을(를) 결합

    결과적으로 두 코드 관리 스타일의 모든 단점이 프로젝트에 결합됩니다. 불필요한 복잡성, 불안정, 유연성 부족을 가중시킨다.

    For example:

    • 개발 팀에 Git 및 Composer 워크플로우(둘 중 하나만 아님)를 모두 설명합니다.
    • app/code에 호환되지 않는 모듈을 설치하십시오. 이를 중지하는 방법은 없습니다.
    • 모듈을 app/code에서 Composer로(또는 반대로) 이동하는 것은 특히 지속적인 개발로 인해 번거롭습니다.
  2. 패키지 관리자 저장

    프라이빗 패커니스트± 연간 600유로입니다. 이 비용은 브랜드당 비용이 아니라 전체 GRA를 합한 비용입니다. 무료 솔루션 Satis를 사용하여 이러한 비용을 방지 하려고 하지 마십시오. Satis는 git에 커밋을 푸시할 때마다 패키지를 자동으로 업데이트하지 않습니다. 또한 Satis는 내장 된 권한 없습니다. Satis를 실행하려면 웹 서버를 유지 관리해야 합니다. Satis를 유지 하는 개인 Packagist 구독 수수료의 다수를 지출하게 됩니다.

  3. Git로 시작한 다음 작성기로 이동

    프로젝트를 시작할 때 코드 관리 접근 방식을 선택합니다. Git에서 작성기로 전환하거나 반대로 지속적인 개발로 인해 번거롭고 코드 손실 및 개정 기록 손실이 발생할 수 있습니다.

recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60