엔드 투 엔드 테스트 업로드 및 구현

확장 테스트에는 Adobe Experience Platform Launch API 및/또는 명령줄 도구를 사용하여 확장 패키지를 업로드한 다음 Platform Launch UI를 사용하여 확장 패키지를 속성에 설치하고 Platform Launch 라이브러리 및 빌드에서 해당 기능을 실행하는 작업이 포함됩니다.

이를 수행하기 위한 기본 단계는 다음과 같습니다.

1. 확장 유효성 검사
2. Adobe I/O 통합 생성
3. 확장 패키지 업로드
4. 개발 속성 생성
5. 확장 설치
6. 확장을 테스트할 리소스 생성
7. 변경 사항 게시
8. 테스트 사이트에 Platform Launch 설치
9. 테스트

테스트하면서(위의 9단계) 수정해야 하는 문제가 발견되면 다음을 수행합니다.

1. 확장 코드 업데이트
2. 새 확장 패키지 생성
3. 새 확장 패키지 업로드 - 설치된 확장이 이 새 패키지를 자동으로 참조합니다.
4. 필요한 경우 리소스 업데이트
5. 다시 게시
6. 테스트

아래 단계에서는 노드 및 npm이 설치 및 사용 가능한 Mac OS를 사용하고 있는 것으로 가정합니다.

확장 유효성 검사

확장의 성능 및 Sandbox 툴에서 볼 수 있는 결과에 팀이 만족하면 확장 패키지를 Platform Launch에 업로드할 수 있습니다.

업로드하기 전에 필수 필드 또는 설정이 있는지 확인하십시오. 예를 들어, 확장 매니페스트, 확장 구성, 보기, 라이브러리 모듈(최소)을 검토하는 것이 좋습니다.

구체적인 예는 로고 파일로, extension.json 파일에 "iconPath": "example.svg", 줄을 추가하고 해당 로고 이미지 파일을 프로젝트에 포함합니다. 이는 Platform Launch 내에 확장에 대해 표시될 아이콘의 상대 경로입니다. 슬래시로 시작하지 않아야 합니다. 확장자가 .svg인 SVG 파일을 참조해야 합니다. SVG는 정사각형을 렌더링할 때 정상적으로 표시되며 사용자 인터페이스에 따라 크기가 조정될 수 있습니다. 자세한 내용은 SVG 비율 조정 방법을 참조하십시오.

Adobe I/O 통합 생성

API 또는 명령줄 도구를 사용하려면 Adobe I/O에 기술 계정이 있어야 합니다. I/O 콘솔에서 기술 계정을 생성한 다음 Uploader 툴을 사용하여 확장 패키지를 업로드합니다.

Platform Launch에서 사용할 기술 계정을 만드는 방법에 대한 자세한 내용은 액세스 토큰 안내서를 참조하십시오.

통합을 생성할 수 없는 경우, 올바른 권한이 없는 것이며 조직 관리자 중 한 명에게 문의하여 귀하가 직접 단계를 완료할 수 없다고 보고하거나 귀하를 개발자로 할당해야 합니다.

확장 패키지 업로드

자격 증명이 정렬되어 이제 확장 패키지를 처음부터 끝까지 테스트할 준비가 되었습니다.

처음 확장 패키지를 업로드하면 development 상태가 됩니다. 즉, 자체 PlatformLaunch 회사에서만 볼 수 있고 확장을 개발하기 위해 표시된 PlatformLaunch 속성만 볼 수 있습니다(자세한 내용은 이후에 설명).

현재 .zip 패키지가 들어 있는 디렉토리 내의 명령줄로 돌아갑니다.

npx @adobe/reactor-uploader

npx를 사용하면 npm 패키지를 컴퓨터에 실제로 설치하지 않고도 다운로드하여 실행할 수 있습니다. 이는 Uploader를 실행하는 가장 간단한 방법입니다.

Uploader가 몇 가지 정보를 입력하도록 요청합니다. 기술 계정 ID, API 키 및 기타 정보 비트는 Adobe I/O 콘솔에서 검색할 수 있습니다. I/O 콘솔의 통합 페이지로 이동합니다. 드롭다운에서 올바른 조직을 선택하고 올바른 통합을 찾은 다음 View​를 선택합니다.

• 개인 키의 경로가 무엇입니까? /path/to/private.key입니다. 이는 위 2단계에서 개인 키를 저장한 위치입니다.
• 조직 ID란 무엇입니까? 이전에 열어 둔 I/O 콘솔 개요 페이지에서 이 내용을 복사하거나 붙여 넣습니다.
• 기술 계정 ID란 무엇입니까? I/O 콘솔에서 복사/붙여넣으십시오.
• API 키란 무엇입니까? I/O 콘솔에서 복사/붙여넣으십시오.
• 클라이언트 암호란 무엇입니까? I/O 콘솔에서 복사/붙여넣으십시오.
• 업로드할 extension_package의 경로는 무엇입니까? /path/to/extension_package.zip입니다. .zip 패키지가 들어 있는 디렉토리 내에서 업로더를 호출하는 경우 경로를 입력하는 대신 목록에서 선택하기만 하면 됩니다.

그러면 확장 패키지가 업로드되고 업로더에서 extension_package의 ID를 제공합니다.

개발 속성 생성

PlatformLaunch에 로그인하면 속성 화면이 먼저 표시됩니다. 속성은 배포하려는 태그의 컨테이너이며 하나 이상의 사이트에서 사용할 수 있습니다.

내 'test' 속성이 여기에 표시되지만 처음 로그인하면 화면에 속성이 표시되지 않습니다. 새 속성​을 선택하여 속성 하나를 만듭니다. 이름 및 URL을 입력합니다. 확장을 테스트할 테스트 사이트 또는 페이지의 URL을 사용하고 싶을 수 있습니다. 이 도메인 필드는 일부 확장이나 코어 확장을 사용하는 조건으로 사용할 수 있습니다(나중에 설명 제공). localhost작동하지 않으므로 localhostURL을 사용하는 경우 example.com과 같은 이 테스트에 아무 값이나 사용하십시오.

확장 개발 테스트에 이 속성을 사용하려면 고급 옵션을 확장하고 "확장 개발을 위한 구성" 상자를 선택해야 합니다.

맨 아래에 있는 저장​을 선택하여 새 속성을 저장합니다.

그러면 속성 화면으로 돌아갑니다. 방금 생성한 속성의 이름을 선택합니다. 속성의 개요 화면입니다. 여기서는 많은 작업이 수행되지 않지만, 맨 위에 전역 탐색 링크를 통해 시스템의 각 영역에 대한 링크가 제공됩니다.

확장 설치

이 속성에 확장을 설치하려면 맨 위에 있는 기본 탐색 링크에서 확장 링크​를 선택합니다.

이 설치 화면에 Core 확장이 표시됩니다. Core 확장에는 Platform Launch 내의 모든 태그 관리 기능이 포함되어 있습니다. 확장을 추가하려면 카탈로그​를 선택합니다.

카탈로그에는 사용 가능한 각 확장에 대한 카드 아이콘이 표시됩니다. 확장이 카탈로그에 표시되지 않으면 먼저 위의 Adobe 관리 콘솔 설정 및 확장 패키지 생성 섹션에 있는 위 단계를 완료했는지 확인하십시오. Platform Launch이 초기 처리를 완료하지 않은 경우 확장 패키지가 보류 중으로 표시될 수도 있습니다.

모든 작업을 올바르게 수행했지만 카탈로그에 보류 중 또는 실패한 확장 패키지가 표시되지 않는 경우 API로 직접 이동하여 확장 패키지의 상태를 확인할 수 있습니다. 자세한 내용은 API 문서에서 ExtensionPackage 가져오기를 참조하십시오.

확장 패키지 처리가 완료된 것으로 가정하면 여기에 있는 카드에 선택할 설치 버튼이 표시됩니다.

그러면 확장용으로 빌드한 구성 화면이 표시됩니다(있는 경우). 확장을 구성하는 데 필요한 정보를 추가하고 맨 아래의 저장​을 선택합니다. 확장이 구성되어 있지 않은 경우 설치​를 선택하는 즉시 설치됩니다.

다음은 Facebook 확장의 예입니다.

이제 Core 확장의 설치됨 확장 화면이 표시됩니다.

확장을 테스트할 리소스 생성

확장은 Platform Launch 사용자에게 새로운 기능을 제공합니다. 이러한 기능은 거의 항상 데이터 요소 또는 규칙 빌더에 표시됩니다. 다음의 두 가지 사항에 대해 알아보겠습니다.

데이터 요소

사용자가 값을 유지할 수 있도록 Platform Launch에서는 데이터 요소가 제공됩니다. 각 데이터 요소는 소스 데이터에 대한 매핑 또는 포인터입니다. 단일 데이터 요소는 쿼리 문자열, URL, 쿠키 값, JavaScript 변수 등으로 매핑될 수 있는 변수입니다.

확장에서는 확장을 운영하기 위해 필요한 경우 또는 간단히 사용자에게 편리한 방식으로 데이터 요소 유형을 정의할 수 있습니다. 확장에서 데이터 요소 유형을 제공하면 새 데이터 요소 만들기 화면의 드롭다운 목록에 표시됩니다.

사용자가 확장 드롭다운에서 확장을 선택하면 데이터 요소 유형 드롭다운에 확장이 제공하는 데이터 요소 유형이 채워집니다. 그런 다음 사용자는 각 데이터 요소를 소스 값에 매핑할 수 있습니다. 그런 다음 데이터 요소 변경 이벤트 또는 사용자 지정 코드 이벤트에서 규칙을 작성하여 실행할 규칙을 트리거할 때 데이터 요소를 사용할 수 있습니다. 데이터 요소는 데이터 요소 조건이나 규칙의 다른 조건, 예외 또는 작업에서 사용할 수도 있습니다.

데이터 요소가 생성되면(매핑 설정됨) 사용자는 데이터 요소를 참조하여 소스 데이터를 참조할 수 있습니다. 값의 소스가 변경된 경우(사이트 재설계 등) 사용자는 Platform Launch에서 매핑을 한 번만 업데이트하면 모든 데이터 요소가 자동으로 새 소스 값을 받게 됩니다.

규칙

상단의 탐색에 있는 규칙 링크를 선택한 다음 규칙 추가​를 선택합니다.

먼저 규칙 이름을 지정합니다. 아무 이름이나 사용할 수 있습니다. 새 규칙 만들기 화면은 다음 if-then 문과 같습니다.

이벤트가 발생하고 조건이 전달되며 예외가 발생하지 않으면 작업이 트리거됩니다. 이벤트, 조건, 예외, 데이터 요소 또는 작업을 만들거나 활용할 수 있는 확장에서도 워크플로가 동일합니다.

Facebook 예시를 계속 진행하여, 사이트에서 페이지가 로드될 때마다 이벤트를 추가하도록 해보겠습니다.

Window Loaded 이벤트 유형을 사용하면, 페이지가 사이트에 로드될 때마다 이 규칙이 트리거됩니다. 저장​을 선택합니다. 이 예시에서는 사이트의 모든 페이지에 대해 이 규칙을 트리거할 수 있도록 "전역" 로드 시 규칙을 설정하여 조건 및 예외 사항을 생략합니다.

작업 아래에서 추가​를 선택합니다. 이 작업 구성 화면에서 작업할 확장과 이 규칙이 트리거될 때 수행할 작업을 선택할 수 있습니다. 확장 아래에서 Facebook Pixel​을 선택하고 작업 유형에서 페이지 보기 전송​을 선택합니다.

하단의 변경 사항 유지​를 선택하고 다음 화면에서 규칙 저장​을 클릭합니다. 확장을 테스트할 때에는 수와 관계없이 확장에서 제공되는 이벤트, 조건 등을 선택할 수 있습니다.

변경 사항 게시

기본 탐색에서 게시​를 선택한 다음 새 라이브러리 추가 링크를 선택합니다.

라이브러리는 확장, 데이터 요소 및 규칙이 서로 및 웹 사이트와 상호 작용하는 방법에 대한 지침 집합입니다. 라이브러리는 빌드에 컴파일됩니다. 라이브러리에는 사용자가 편리하게 한 번에 생성 및 테스트할 수 있도록 여러 변경 사항이 포함될 수 있습니다.

새 라이브러리 만들기 화면에서 이름을 추가하고 환경을 선택합니다. Platform Launch는 이름이 Development인 기본 개발 환경을 제공하므로 환경 목록에서 해당 개발 환경을 선택합니다. 지금은 사용 가능한 모든 리소스를 추가하기 때문에 변경된 모든 리소스 추가​를 선택합니다.

그런 다음, 맨 아래의 저장​을 선택합니다. 이제 이 dev 라이브러리에 모든 변경 사항이 포함되었으므로 빌드해 보겠습니다.

빌드 프로세스가 완료되면 라이브러리 이름 옆에 녹색 성공 표시기가 표시됩니다.

이제 Platform Launch 라이브러리가 게시되어 사용 대기 중입니다. 이제 브라우저에서 최종 사용자에 대한 동작을 테스트할 수 있도록 테스트 페이지에 이 라이브러리를 검색하도록 해야 합니다.

테스트 사이트에 Platform Launch 설치

설치 지침은 환경 탭에서 확인할 수 있으므로 지금 살펴보도록 하겠습니다.

이 페이지에서는 사용 가능한 모든 환경을 볼 수 있으며 더 많은 환경을 생성할 수 있습니다. 라이브러리를 개발 환경에 게시했으므로 개발 행의 설치 열에 있는 상자 아이콘을 선택하여 해당 환경에 대한 설치 지침을 가져오겠습니다.

이제 개발 환경에 대한 설치 지침을 살펴보겠습니다. 여기에서는 상자에 있는 <script> 태그를 복사해야 하므로 복사 버튼을 선택합니다.

문서 또는 사이트 템플릿의 <head> 섹션 내에 이 단일 <script> 태그를 배치하여 설치를 완료합니다. 이제 테스트 사이트로 이동하여 게시된 Platform Launch 실행 라이브러리의 동작을 테스트해 보십시오.

테스트

테스트 페이지 또는 사이트에서 확장을 확인하는 동안 유용한 몇 가지 콘솔 명령이 있습니다.

• _satellite.setDebug(true);은(는) Platform Launch를 디버그 모드로 전환하고 유용한 로깅 문을 콘솔에 출력합니다.
• _satellite._container 객체에는 포함된 빌드, 데이터 요소, 규칙 및 확장에 대한 세부 사항을 비롯하여 배포된 라이브러리에 대한 모든 종류의 유용한 정보가 포함되어 있습니다.

마지막으로 여기서의 목표는 Platform Launch가 라이브러리를 컴파일할 때 확장 패키지 내에서 작성한 코드가 예상대로 작동할 수 있도록 배포된 라이브러리의 기능을 테스트하는 것입니다.

확장 패키지를 변경해야 하는 경우 반복되는 프로세스는 개발 프로세스와 유사합니다.

1. 프로젝트 코드 변경
2. Sandbox 툴을 사용한 변경 사항 유효성 검사
3. Packager 툴을 사용한 새 .zip 패키지 만들기
4. Uploader 툴을 사용하여 새 .zip 패키지를 업로드합니다. 초기 업로드에 대해 위와 동일한 지침을 따를 수 있지만, 이번에는 개발 모드에 이미 해당 이름의 확장 패키지가 있기 때문에 새 패키지를 만드는 대신 다른 패키지를 덮어쓰게 됩니다. 자격 증명을 반복해서 입력하지 않고 시간을 절약하려면 리액터-업로더 설명서를 확인하고 명령줄에 인수를 전달할 수 있습니다.
5. 이번에는 설치 단계를 건너뛸 수 있습니다.
6. 리소스 수정 - 확장 구성 요소의 구성을 변경한 경우 Platform Launch UI에서 해당 리소스를 업데이트할 수 있습니다.
7. 라이브러리에 최신 변경 내용을 추가하고 다시 빌드합니다.
8. 추가 테스트를 수행합니다.