앱 배포

애플리케이션이 빌드되고 유효성이 검사되면 애플리케이션을 프로덕션 환경으로 이동해야 합니다. 애플리케이션은 애플리케이션 리포지토리를 통해 또는 업데이트 세트를 사용하여 이동할 수 있습니다. 프로덕션으로 이동하기 전에 테스트 환경에 애플리케이션을 배포해야 합니다.

애플리케이션 리포지토리(앱 리포지토리)

애플리케이션을 앱 리포지토리에 게시하면 조직의 모든 ServiceNow 인스턴스에서 이 버전의 애플리케이션을 사용할 수 있습니다. 앱 리포지토리를 사용하여 QA/테스트 인스턴스(테스트용)에 애플리케이션을 배포하고 마지막으로 프로덕션(프로덕션) 인스턴스에 배포합니다.

자세한 내용은 애플리케이션 리포지토리에 애플리케이션 게시, 애플리케이션 설치를 참조하세요.

업데이트 세트

애플리케이션 리포지토리를 사용하여 애플리케이션을 배포할 수 없는 경우 대신 업데이트 세트를 사용하십시오. 다이어그램은 개발 인스턴스에서 테스트 인스턴스로 사용자 지정을 배포하기 위한 업데이트 세트의 베스트 프랙티스 수명주기를 보여줍니다.

고품질 개발 및 릴리스 프로세스로 이어지는 프랙티스:

• 사용자 지정은 항상 스택의 맨 아래에서 위로 이동합니다.
  • 다운 스택 인스턴스가 업 스택 인스턴스와 일치하는지 확인합니다.
  • 스택 중간에 도입된 커스터마이제이션은 다운스택의 향후 푸시에 의해 덮어쓰여질 수 있습니다.
  • 일반적인 시나리오는 다음과 같습니다.
    • 테스트 또는 프로덕션에서 수정이 필요함 – 항상 개발에서 푸시하십시오.
    • 선택 목록과 같은 일반적인 제품 관리자 사용자 지정 - 항상 개발에서 업데이트 푸시
• 이전하기 전에 항상 업데이트 세트에 포함된 업데이트를 검토하십시오.
  • 테스트와 관련된 다른 개발 작업 및 업데이트와 관련된 업데이트를 찾습니다.
  • 시스템 속성 및 통합 엔드포인트 변경을 관찰합니다. 예: 모든 이메일을 테스트 이메일 계정으로 보내는 sys_properties 변경 밀어넣기
  • 업데이트를 삭제하는 대신 업데이트를 "스크랩" 업데이트 세트로 이동합니다.
• 밀어넣은 후에는 항상 테스트하여 원하는 모든 커스터마이제이션이 캡처되고 예상대로 적용되는지 확인합니다.
• 여러 릴리스가 병렬로 배포되는 상황에서는 개발 팀 간의 커뮤니케이션과 조율을 유지하십시오.
• 사용자 지정이 실수로 캡처되어 다른 팀 구성원에 의해 마이그레이션될 수 있으므로 개발 인스턴스에서 실험하지 마십시오.
• 기본 업데이트 세트에서 개발을 캡처하지 마십시오.

업데이트 세트의 설명 필드에 간단한 설명과 함께 모든 사용자 스토리 번호를 나열합니다. 업데이트 세트 배포에 필요한 모든 수동 단계를 포함합니다.

업데이트 세트에서 캡처되지 않은 배포에 필요한 수동 단계의 몇 가지 일반적인 예는 다음과 같습니다.

• 플러그인 활성화.
• 업데이트 세트에서 추적되지 않는 테이블(일반적으로 "x_" 또는 "u_"로 시작)의 전송
• 테이블에 데이터베이스 인덱스를 생성합니다. 인덱스 생성은 업데이트 세트를 통해 추적되지 않으며 수동으로 수행해야 합니다.

업데이트 세트 관리

스토리 또는 결함에 대해 작업할 때는 올바른 업데이트 세트가 선택되었는지 확인하고 매일 업데이트 세트의 기록을 점검하십시오.

업데이트 세트 간에 sys_update_xml 기록을 수동으로 이동하지 마십시오. 유일한 예외는 기록을 기본 업데이트 세트로 이동하는 것입니다.

업데이트 세트는 구성 정보를 캡처하지만 작업 또는 프로세스 데이터는 캡처하지 않습니다. 예를 들어, 업데이트 세트는 Service Catalog 항목 정의와 관련 구성 데이터(예: 변수 및 변수 선택)를 추적합니다. 그러나 테스트에 배치된 주문(요청, 항목, 카탈로그 작업)은 업데이트 세트에서 추적되지 않습니다.

업데이트 세트의 해야 할 일과 하지 말아야 할 일에 유의하십시오.

• 현재 업데이트 세트에서 특정 sys_update_xml 기록을 제거하려면 기록을 기본 업데이트 세트로 이동하고 기록을 기본 업데이트 세트로 이동하는 이유로 기록의 sys_update_set.comments 필드를 채웁니다.
• 한 업데이트 세트에서 다른 업데이트 세트로 사용자 지정 기록을 이동하지 마십시오.
• 업데이트 세트가 새 업데이트 세트에 병합되지 않은 경우에는 업데이트 세트를 삭제하지 마십시오.
• 항상 데이터 추출 또는 임포트 세트를 사용하여 한 인스턴스에서 다른 인스턴스로 데이터를 이동합니다(업데이트 세트는 아님).

업데이트 세트 일괄 처리

일괄 업데이트 세트를 사용하여 업데이트 세트를 대량으로 미리 보고 커밋할 수 있습니다.

여러 업데이트 세트를 처리하다 보면 잘못된 순서로 업데이트 세트를 커밋하거나 하나 이상의 세트를 실수로 제외하는 등의 문제가 발생할 수 있습니다. 완료된 업데이트 세트를 배치로 그룹화하여 이러한 문제를 방지하십시오.

시스템은 업데이트 세트 배치를 계층 구조로 구성합니다. 하나의 업데이트 세트가 여러 하위 업데이트 세트의 상위 역할을 할 수 있습니다. 지정된 세트는 하위일 수도 있고 상위일 수도 있으므로 여러 수준의 계층 구조를 사용할 수 있습니다. 계층 구조의 최상위 수준에 있는 하나의 업데이트 세트가 기본 업데이트 세트의 역할을 합니다.

기본 업데이트 세트를 미리 보거나 커밋하면 전체 배치가 미리 보이거나 커밋됩니다. 시스템은 처리 순서를 결정하고 변경 내용이 기록된 날짜와 순차적 상위 항목을 기준으로 충돌을 검사합니다. 상위 항목은 업데이트 세트에서 변경이 발생한 특정 인스턴스입니다.

업데이트 세트 배치는 릴리스에 적용할 수 있으며, 여기서 릴리스에 대해 빈 상위 업데이트 세트가 생성되고 실제 업데이트 세트는 릴리스에 하위 항목으로 포함됩니다.

업데이트 세트 일괄 처리를 사용하면 다음과 같은 이점이 있습니다.

• 개별 업데이트 세트는 마지막 순간에 릴리스에서 제거할 수 있습니다.
• 일괄 처리는 일괄 처리를 통해 업데이트를 제거할 수 있다는 점을 제외하고는 병합과 유사합니다.
• 배치 업데이트 세트는 쉽게 배포할 수 있습니다. 상위 업데이트 세트만 처리하면 됩니다.

자세한 내용은 시스템 업데이트 세트를 참조하십시오.

다음에 할 일

이제 앱이 배포되었으므로 어떻게 개선하고 향상할지 생각해 보십시오. 다음은 다음에 어디로 갈지 결정하기 위한 몇 가지 제안 사항입니다.

• 매일 애플리케이션을 사용하는 사람들이 최고의 피드백 소스가 될 것입니다. 어떤 새로운 기능이나 변경 사항을 보고 싶은지 이야기하십시오.
• Flow Designer를 통해 추가 관련 프로세스 흐름을 자동화할 수 있는지 확인합니다.
• 새 통합 허브 스포크를 새 통합에 활용할 수 있는지 확인합니다.