업데이트 세트 시작하기
업데이트 세트는 인스턴스를 변경하므로 이 정보를 검토하여 오류 및 성능 문제를 방지하십시오. 업데이트 프로세스를 계획하고 일반적인 실수를 방지하는 방법을 알아봅니다.
업데이트 세트를 사용해야 하는 경우
| 배포 옵션 | 추천: | 향후 고려 사항 |
|---|---|---|
| 업데이트 세트 | 기본 시스템 또는 설치된 애플리케이션에 대한 변경 내용을 저장합니다. 특정 버전의 애플리케이션을 저장하고 적용합니다. 내보낼 파일을 생성합니다. |
업데이트 세트를 수동으로 생성하여 특정 애플리케이션 버전을 저장할 수 있습니다. 업데이트 세트를 사용하여 설치된 애플리케이션에 패치 또는 변경 사항을 배포합니다. 주: 업데이트 세트를 사용하여 애플리케이션을 설치하지 마십시오. 대신 애플리케이션 리포지토리 또는 ServiceNow Store 를 사용하여 애플리케이션을 설치하십시오. |
| 애플리케이션 리포지토리 | 모든 회사 인스턴스에 애플리케이션 설치 및 업데이트 애플리케이션 업데이트 세트를 자동으로 관리합니다. 애플리케이션에 대한 액세스를 동일한 회사로 제한합니다. 완성된 애플리케이션을 최종 사용자에게 배포. |
애플리케이션을 업로드하여 ServiceNow Store 다른 사용자와 공유하는 것이 좋습니다. 최신 애플리케이션 버전만 설치하고 업데이트할 수 있습니다. 업데이트 세트를 사용하여 이전 애플리케이션 버전을 저장합니다. 주: 팀 개발과 함께 사용하는 경우 상위 인스턴스에서만 애플리케이션을 게시합니다. |
업데이트 프로세스 계획
업데이트 세트 작업을 하기 전에 다음 검사 목록을 사용하여 사용자 지정을 한 인스턴스에서 다른 인스턴스로 옮기는 표준 프로세스를 생성하십시오.
- 두 인스턴스가 모두 같은 버전인지 확인합니다. 버전마다 다른 코드에 의존할 경우 사용자 지정이 작동할 수 없습니다.
- 단일 업데이트 세트에서 변경할 사항을 결정합니다. 중소 규모의 작업을 마치면 업데이트 세트를 완료합니다. 업데이트 세트가 커질수록 업데이트 세트를 검토하기가 더 어려워지고, 그 안에서 변경 내용을 식별하는 데 시간이 오래 더 걸리며, 다른 업데이트 세트와 충돌할 위험이 증가하고, 업데이트 세트를 미리 보고 커밋하는 데 더 많은 시간이 소요됩니다. 업데이트 세트에 대규모 워크플로우에 대한 스키마 변경 또는 수정 버전이 포함되어 있는 경우 혹은 세트를 원상복구해야 하는 경우에는 특히 그렇습니다.
- 모든 기본 시스템 기록에 일치하는 sys_id 필드가 있는지 확인합니다. 일부 기본 시스템 기록은 프로비저닝 이후에 인스턴스에 생성되어 인스턴스마다 달라 업데이트 세트에 문제가 생길 수 있기 때문입니다. 이 문제를 피하는 가장 좋은 방법은 다음 작업을 수행하는 것입니다.
- 프로덕션 및 비프로덕션 인스턴스를 프로비저닝합니다.
- 프로덕션 인스턴스를 비프로덕션 인스턴스로 복제합니다.
- 업데이트 세트가 한 인스턴스에서 다른 인스턴스로 이동하는 공통 경로를 식별하고 해당 모델을 유지관리합니다. 여러 소스에서 동일한 업데이트 세트를 마이그레이션하지 마십시오. 업데이트 세트를 개발에서 테스트로, 그런 다음 테스트에서 프로덕션으로 이동합니다.
- 업데이트 세트를 프로덕션에 커밋할 시기를 계획합니다. 업무 시간 중에는 업데이트 세트를 프로덕션 인스턴스에 커밋하지 마십시오. 업데이트 세트가 적용되는 동안에는 인스턴스의 수행 속도가 느려질 수 있습니다. 이 느린 성능은 일시적이므로 안심하십시오.
- 업데이트 세트 이름은 명확해야 합니다. 명명 규칙을 생성하여 여러 개발자가 변경한 사항을 조정하고 해당 변경 사항을 다른 인스턴스에 커밋할 때 참조할 수 있도록 합니다.
- 업데이트 세트가 문제에 대한 수정 사항으로 생성되는 경우 이름에 문제 티켓을 포함하는 것이 좋습니다(예: PR10005 - 중복 이메일 문제 수정).
- 문제를 해결하기 위해 두 개 이상의 업데이트 세트가 필요한 경우 명명 규칙에 시퀀스 번호를 포함합니다. 이렇게 하면 업데이트 세트가 생성된 순서대로 적용됩니다(예: PR10005 - 중복 이메일 문제 수정 및 PR10005.2 - 중복 이메일 문제 수정).
- 업데이트 세트에 대해 다음 사항을 파악합니다.
- 생성되는 기록
- 추적되는 사용자 지정
- 유효한 딕셔너리 변경 내용
- 적용된 후 원상복구할 수 있는(되돌릴 수 있는) 사용자 지정
- 사용자 지정을 하기 전에 올바른 업데이트 세트가 선택되었는지 다시 확인하십시오.
업데이트 세트 작업
오류 및 성능 문제를 방지하려면 이 정보를 검토하십시오.
- 업데이트 세트를 삭제하지 마십시오. 업데이트 세트가 삭제되면 업데이트된 기록이 다음 업데이트에서 덮어쓰여질 수 있습니다.
- 업데이트 세트에 ldap_server_config 기록의 system_id 필드를 포함하지 마십시오. 작동 중인 구성의 업데이트 세트가 대상 인스턴스의 잘못된 system_id 노드를 가리키고 작동하지 않습니다.
- 기본 업데이트 세트를 원상복구하지 마십시오. 이 작업은 시스템을 손상시킵니다.
- 고객 업데이트 기록(sys_update_xml)의 업데이트 세트 필드 값(update_set)을 변경하지 마십시오. 잘못된 업데이트 세트에서 사용자 지정이 이루어질 경우 다음 조치를 취하십시오.
- 올바른 업데이트 세트로 전환합니다.
- 원래 변경된 객체(기록)를 수정합니다. 필드를 추가하는 등의 사소한 변경 작업을 수행할 수 있습니다.
- 기록을 저장합니다.
- 방금 수행한 변경을 원상복구한 다음 기록을 다시 저장합니다.
이렇게 하면 객체의 최신 버전이 올바른 업데이트 세트에 포함되며 단일 업데이트 세트에서 동일한 객체에 대해 업데이트가 중복되는 것을 방지합니다.
- 마이그레이션할 준비가 될 때까지 업데이트 세트를 완료 로 표시하지 마십시오. 업데이트 세트가 완료된 후에는 다시 진행 중으로 변경하지 마십시오. 대신 나머지 변경 내용에 대해 다른 업데이트 세트를 생성하고, 변경 내용이 생성된 순서대로 함께 커밋해야 합니다. 이 경우 명명 규칙이 도움이 될 수 있습니다(예: 성능 향상 및 성능 향상 2).
- 업데이트를 업데이트 세트에 수동으로 병합하지 마십시오. 업데이트 세트 병합 모듈을 사용합니다. 이 도구는 업데이트 세트 간에 중복 파일을 비교하여 최신 버전을 선택합니다.
- 커밋된 업데이트 세트가 테스트 인스턴스에서 문제를 일으키는 경우, 개발 인스턴스의 또 다른 업데이트 세트에 수정 사항을 빌드하십시오. 이 세트를 테스트 인스턴스에 커밋한 다음 두 세트 모두가 프로덕션 인스턴스로 마이그레이션되는지 그리고 만들어진 순서대로 커밋되었는지 확인합니다.
- 업데이트 세트를 커밋하기 전에 항상 미리 확인하십시오.
- 프로덕션 인스턴스에서 완료된 업데이트 세트를 무시로 설정하십시오. 이렇게 하면 인스턴스를 복제할 때 업데이트 세트가 다시 적용되지 않습니다.
- 업데이트 세트가 적용된 후 완료해야 하는 수동 변경 및 데이터 로드가 담긴 할 일 목록을 작성하여 보관하십시오.
- 한 번에 너무 많은 것을 변경하지 마십시오. 올바른 변경이 점진적으로 이루어졌는지 확인해야 합니다.
- 단일 업데이트를 변경하여 여러 도메인(즉, 전역 및 TOP 도메인)에 걸쳐 업데이트할 수 없습니다. 이 함수는 Now Platform.