프로덕션 배포 팁

  • 릴리스 버전: Washingtondc
  • 업데이트 날짜 2024년 02월 01일
  • 읽기6분
  • 플랫폼에서 애플리케이션에 대한 사용자 지정을 ServiceNow® 개발할 때 애플리케이션 리포지토리를 통해 프로덕션 인스턴스에 배포합니다. 이 항목에서는 응용 프로그램 리포지토리에서 응용 프로그램을 설치하는 경우와 소스 제어가 있는 Git 리포지토리에서 응용 프로그램을 설치하는 경우의 장단점을 살펴보고 주의 사항을 제공합니다.

    개요

    기술적으로는 소스 제어를 사용하여 Git 리포지토리에서 프로덕션 인스턴스로 애플리케이션을 "배포"할 수 있습니다. 이로 인해 의도하지 않은 결과가 발생할 수 있습니다.

    용어집

    용어 정의
    메타데이터 또는 애플리케이션 파일 애플리케이션에서 ServiceNow 구성을 정의하고 애플리케이션으로 패키지되는 sys_metadata 기록입니다. 이러한 기록은 인스턴스의 동작을 변경하지만 인시던트 또는 CMDB 기록과 같은 데이터는 포함하지 않습니다. (아래 참고 참조)
    범위가 지정된 애플리케이션 범위 경계 내의 업데이트 및 작업만 허용을 제한하는 ServiceNow 애플리케이션입니다. 이 메커니즘은 대부분의 새로운 개발에 사용됩니다.
    전역 애플리케이션 전역 응용 프로그램은 레거시 전역 범위에서 개발됩니다. 작업은 주로 이 범위에서 수행되어 ITSM(IT Service Management)과 같은 기존 ServiceNow 애플리케이션을 사용자 지정합니다.
    애플리케이션 리포지토리 애플리케이션은 일반적으로 프로덕션 인스턴스에 배포하기 위해 여기에 게시됩니다. 애플리케이션 리포지토리에는 별도의 권리 규칙이 있지만 ServiceNow Store와 유사하게 작동합니다.
    ServiceNow Store 외부 공급업체(벤더) 애플리케이션과 ServiceNow 게시 애플리케이션에 대한 리포지토리입니다. 대부분의 고객은 스토어에 게시하지 않지만 스토어에서 애플리케이션을 설치하는 경우가 많습니다.
    업데이트 세트 각 연속 인스턴스에 배포할 사용자 지정 항목을 패키징하는 표준 방법입니다. 여기에는 삽입, 업데이트 및 삭제의 증분 컬렉션이 포함됩니다.
    델타 로딩 중 가장 효율적인 로딩 방법은 이전의 제거/재설치 방법이 아닌 소스 제어에서만 변경되기 때문입니다.
    스키마 테이블 및 테이블의 열에 대한 정의입니다.
    롤백 관리자는 선택한 애플리케이션의 마지막 설치를 롤백할 수 있습니다. 롤백은 초기 설치에서 모든 코드, 테이블 및 파일 업데이트를 제거합니다.
    주:
    sys_metadata 테이블은 테이블 상속 모델을 사용하는 플랫폼에 있는 ServiceNow 모든 애플리케이션 파일의 상위 테이블입니다. 테이블(sys_db_object 기록의 테이블 확장(super_class) 필드에 표시된 대로 직접 또는 간접적으로 확장되는 상위 테이블을 방문하여 메타데이터에 대한 요약 정보를 볼 수 있습니다. sys_metadata 테이블에 대한 테이블(sys_db_object) 양식을 방문하고 양식 하단에 있는 스키마 맵 표시 관련 링크를 선택하여 전체 스키마를 볼 수도 있습니다. 스키마가 커서 렌더링하는 데 시간이 걸립니다.

    스키마 매핑

    스키마 맵 목차

    설치 위치

    소스 통제를 설치하면 사용자 지정 애플리케이션의 지속적인 개발이 용이해집니다. 따라서 애플리케이션은 스토어 애플리케이션 [sys_store_app] 테이블에서 "설치된" 애플리케이션이 아니라 사용자 지정 애플리케이션 [sys_app] 테이블에서 "개발 중" 애플리케이션으로 관리됩니다. 두 테이블 모두 sys_scope의 확장이므로 범위와 동일한 보호 및 제한 사항을 제공합니다. 따라서 소스 통제가 배포된 응용 프로그램의 설치를 검색할 때는 시스템 응용 프로그램 [sys_app] 테이블과 응용 프로그램 관리자 페이지의 개발 중 섹션을 참조하십시오.

    ServiceNow Store 또는 애플리케이션 리포지토리에서 동일한 애플리케이션을 배포하는 동안에는 인스턴스에 대한 sys_app 기록을 가질 수 없습니다. 두 배포 모델은 함께 사용할 수 없습니다. 배포 모델이 변경되면 먼저 sys_app 레코드를 sys_store_app 레코드로 변환해야 합니다. 해당 작업 수행에 대한 도움이 필요하면 ServiceNow 지원에 문의할 수 있습니다.

    델타 로딩 중

    ServiceNow Paris 릴리스 이전에는 소스 통제에서 애플리케이션 설치가 트리거될 때 원격 변경 내용 적용 기능을 포함하여 전체 애플리케이션을 항상 제거하고 다시 설치했습니다. 를 사용하면 델타 로딩 중이제 변경 사항만 업데이트되어 프로세스가 상당히 단순화됩니다.

    델타 로드 프로세스는 소스 제어에서 변경 내용을 증분 방식으로 로드합니다. 원격 변경 내용을 적용할 때 리포지토리에서 제거되지 않는 한 기존 테이블 또는 열을 삭제하지 않습니다. 이렇게 하면 계속 존재하는 테이블 및 필드의 데이터가 보존됩니다.
    주:
    glide.source_control.allow_delta_loading_in_scopedapp 속성을 사용하면 Paris에서 델타 로드를 비활성화할 수 있습니다. 그러나 이것은 응용 프로그램을 제거하고 다시 설치하는 더 파괴적인 동작으로 되돌아갑니다. 파리의 전역 응용 프로그램은 항상 델타 로드를 사용합니다.
    다음은 델타 로드를 사용하는 인스턴스에서 예상되는 여러 결과의 테이블입니다.
    애플리케이션 유형 설치 소스 패키지에 스키마가 있습니다. 스키마에 데이터가 포함됨 다른 앱에서 클레임(전역) 데이터 및 스키마에 대한 예상 결과
    범위가 지정됨 애플리케이션 리포지토리 또는 스토어 예/아니요 해당 사항 없음 보존
    범위가 지정됨 애플리케이션 리포지토리 또는 스토어 아니요 예/아니요 해당 사항 없음 보존
    범위가 지정됨 소스 통제 예/아니요 해당 사항 없음 보존
    범위가 지정됨 소스 통제 아니요 예/아니요 해당 사항 없음 제거됨
    전역 소스 통제, 애플리케이션 리포지토리 또는 스토어 예/아니요 예/아니요 보존
    아니요 아니요 보존됨 (1)
    아니요 아니요 보존됨 (2)
    소스 통제 아니요 아니요 아니요 제거됨(3)
    애플리케이션 리포지토리 아니요 아니요 아니요 보존
    주:
    1: 데이터베이스 스키마와 데이터가 보존되는 동안 기본 전역 애플리케이션으로 이동됩니다.
    주:
    2: 데이터베이스 스키마와 데이터가 보존되는 동안 설치된 경우 이전에 이러한 파일에 대한 클레임을 보유했던 전역 애플리케이션으로 이동됩니다. 그렇지 않으면 기본 전역 애플리케이션으로 이동합니다.
    주:
    3: u_ 접두사가 있는 사용자 지정 열에만 적용할 수 있습니다. ServiceNow 플랫폼에서 작성한 열은 삭제되지 않습니다.

    범위가 지정된 애플리케이션에 대한 소스 통제에서 분기를 전환할 때는 프로덕션 환경에서 각별히 주의해야 합니다. 대상 분기에 현재 분기에 있는 스키마 요소가 없는 경우 관련 스키마가 삭제되고 포함된 모든 데이터가 삭제됩니다. (전역 응용 프로그램은 데이터가 있는 경우 스키마를 삭제하지 않습니다.)

    업데이트 세트와 마찬가지로 증분 변경의 하위 세트만 델타 로드에 적용하면 됩니다. 업데이트 세트와 달리 애플리케이션 패키지는 전체 애플리케이션을 나타냅니다. 새 패키지에 없는 파일은 삭제됩니다. 이로 인해 기능이 변경되고 데이터가 삭제될 수 있습니다. 애플리케이션 리포지토리 또는 ServiceNow 스토어에서 업그레이드한 업데이트 세트와 애플리케이션에는 파일을 제거하거나 스키마를 삭제하기 위한 명시적인 DELETE 페이로드가 있어야 합니다.

    애플리케이션 파일이 어떤 방식으로든 동적으로 생성되는 경우, 다음 설치/적용 원격은 애플리케이션의 작업을 변경하고 해당 기록을 삭제합니다. 들어오는 응용 프로그램 패키지에 없는 것으로 간주됩니다. 로컬 변경사항을 스태시하는 경우 스태쉬 커미트로 애플리케이션 파일을 복구할 수 있지만 변경으로 인해 데이터가 손실되면 데이터가 복구되지 않습니다.
    주:
    sys_update_xml 레코드를 제거하거나 표시하지 않으면 델타 로드에 의해 제거되지 않습니다. 그러나 이 조치는 다른 심각하거나 바람직하지 않은 결과를 초래할 수 있습니다.

    리포지토리에 대한 직접 편집, 특히 파일 제거는 데이터 손실 및 계단식 삭제를 포함하여 상당한 결과를 초래할 수 있습니다. 이 작업은 주의해서 수행해야 합니다.