앱 배포

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

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

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

자세한 정보는 애플리케이션 리포지토리에 애플리케이션 게시, 애플리케이션 설치를 참조하십시오.

업데이트 세트

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

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

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

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

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

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

업데이트 세트 관리

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

업데이트 세트 간에 sys_update_xml 기록을 수동으로 옮기지 마십시오. 단, 기록을 기본 업데이트 세트로 옮기는 경우는 예외입니다.

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

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

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

업데이트 세트 배치

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

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

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

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

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

업데이트 세트 배치를 사용하면 다음과 같은 이점이 있습니다.

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

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

다음에 할 일

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

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