프로덕션 배포 팁

  • 릴리스 버전: Yokohama
  • 업데이트 날짜 2025년 01월 30일
  • 읽기6분

    • 플랫폼에서 애플리케이션에 ServiceNow® 대한 사용자 지정을 개발할 때는 애플리케이션 리포지토리를 통해 프로덕션 인스턴스에 배포합니다. 이 항목에서는 애플리케이션 리포지토리에서 애플리케이션을 설치하는 것과 소스 제어를 사용하는 Git 리포지토리 간의 장단점을 살펴보고 주의 사항을 제공합니다.

    개요 또는 프로덕션에 배포

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

    용어집

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

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

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

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

    리포지토리를 직접 편집하는 경우, 특히 파일을 제거하기 위해 편집하면 데이터 손실 및 연속 삭제 등 상당한 영향을 미칠 수 있습니다. 이 작업은 주의해서 수행하십시오.