앱 배포

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

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

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

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

업데이트 세트

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

품질 개발 및 릴리스 프로세스로 이어지는 관행:

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

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

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

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

업데이트 세트 관리

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

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

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

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

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

업데이트 세트 일괄 처리

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

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

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

기본 업데이트 세트를 미리 보거나 커밋하면 전체 배치를 미리 보거나 커밋할 수 있습니다. 시스템은 처리 순서를 결정하고, 변경 사항이 기록된 날짜와 순차적 상위 항목에 기반하여 충돌을 검사합니다. 이들의 조상은 업데이트 세트에서 변경이 발생한 특정 인스턴스입니다.

업데이트 세트 배치는 릴리스에 대해 빈 상위 업데이트 세트가 생성되고 실제 업데이트 세트는 하위 릴리스로 포함된 릴리스에 적용할 수 있습니다.

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

• 마지막 순간에 개별 업데이트 세트를 릴리스에서 제거할 수 있습니다.
• 일괄 처리는 병합과 비슷하지만 일괄 처리를 통해 업데이트를 제거할 수 있습니다.
• Batch Update Sets는 쉽게 배포할 수 있습니다. 상위 업데이트 세트만 처리해야 합니다.

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

다음에 할 일

이제 앱이 배포되었으므로 앱을 개선하고 향상시키는 방법에 대해 생각해 보십시오. 다음은 다음에 갈 곳을 결정하기 위한 몇 가지 제안입니다.

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