이 문서는 Sandbox와 대상(프로덕션) 간의 동기화가 작동하는 방식을 설명하며, 이 과정에 영향을 미치는 주요 요소들, 특히 내부 이름의 역할과 구성 생성 및 동기화에 미치는 영향을 중점적으로 다룹니다.
목차
동기화 과정에서의 내부 이름의 역할
워크플로우 자동화, 부서, 필드 등과 같은 구성을 생성할 때마다 고유 식별자인 내부 이름이 자동으로 생성됩니다. 내부 이름은 다음과 같습니다:
사용자 인터페이스에 표시되지 않습니다. 백엔드에서 생성됩니다.
Sandbox와 프로덕션 환경 모두에서 구성을 식별합니다.
내부 이름은 어떻게 생성되나요?
구성이 생성되면 시스템이 내부 이름을 생성합니다.
예시: IT 작업 공간의 Development라는 워크플로우 자동화의 경우, 내부 이름은 IT_Development입니다.
이것은 각 작업 공간 내에서 구성이 고유하게 식별되도록 보장합니다.
참고:
구성이 나중에 이름이 변경되더라도 내부 이름은 변경되지 않습니다.
Sandbox에서 구성을 삭제하고 다시 생성하면 내부 이름이 Production과 다를 경우 동기화 충돌이 발생하여 중복되거나 의도하지 않은 구성이 생성될 수 있습니다.
내부 이름 존재 여부에 따른 동기화 동작
Sandbox에서 Production으로 또는 그 반대로 구성을 동기화할 때, 동기화 프로세스는 대상(Production)에서 내부 이름을 확인합니다. 다음 표는 동기화 프로세스의 결과를 설명합니다.
참고: 필드 이름의 경우 동작이 다르며, Sandbox에서 변경된 내용이 대상의 필드와 병합됩니다.
다음 흐름도는 동기화 프로세스를 설명합니다.
Example scenarios
구성 이름 변경
초기 설정
IT 작업 공간에서, 워크플로우 자동화기를 Development 라는 이름으로 샌드박스와 프로덕션 모두에 생성합니다.
내부 이름은 두 환경 모두에서 IT_Development 로 생성됩니다.
샌드박스에서 이름 변경
샌드박스에서 워크플로우 자동화기의 이름을 Development 에서 Engineering로 변경합니다. 보이는 워크플로우 이름은 변경되지만, 내부 이름은 IT_Development로 유지됩니다.
샌드박스를 프로덕션으로 동기화
동기화 중에 시스템은 내부 이름 IT_Development가 프로덕션에 존재함을 감지합니다.
샌드박스의 워크플로우 자동화기(현재 이름 Engineering)는 프로덕션의 자동화기(여전히 이름 Development)를 덮어씁니다.
결과
동기화 실패 또는 덮어쓰기가 발생하는 이유는 내부 이름이 새로운 워크플로우 이름을 반영하도록 업데이트되지 않기 때문입니다.
삭제 및 재생성
샌드박스 및 프로덕션에서의 초기 설정
샌드박스와 프로덕션 모두에서 엔지니어링이라는 부서가 있습니다.
프로덕션에서 엔지니어링을 UX/UI 디자인으로 이름을 변경하지만 내부 이름은 동일하게 유지됩니다.
샌드박스에서 삭제 및 재생성
샌드박스에서 기존의 엔지니어링 부서를 삭제하고 UI/UX 디자인이라는 새 부서를 만듭니다. 그러나 UI/UX 디자인의 내부 이름은 프로덕션과 샌드박스에서 다릅니다.
샌드박스를 프로덕션으로 동기화
동기화 중에 Freshservice는 UI/UX 디자인 샌드박스에서 완전히 새로운 부서로, 프로덕션에서 이름이 변경된 부서의 내부 이름과 더 이상 일치하지 않기 때문에 (Engineering → UX/UI Design).
이로 인해 데이터 충돌이 발생합니다. 두 부서가 프로덕션에서 동일한 표시 이름을 가질 수 없기 때문입니다 (UI/UX Design).
결과
프로덕션에서 기존 부서를 업데이트하는 대신, 중복된 부서가 생성되거나 이름 충돌로 인해 동기화가 실패할 수 있습니다.
필드 선택은 항상 병합되며, 덮어쓰지 않습니다
샌드박스와 프로덕션에서의 초기 설정
샌드박스와 프로덕션 모두에서 우선순위라는 사용자 정의 필드가 있으며, 다음과 같은 선택 사항이 있습니다:
낮음, 중간, 높음.
샌드박스에서 필드 선택 업데이트
샌드박스 환경에서 우선순위 필드를 다음과 같이 선택지를 대체하여:
매우 낮음, 보통, 매우 높음.
샌드박스를 프로덕션으로 동기화
동기화 중에 Freshservice는 샌드박스의 필드 선택지를 프로덕션의 것과 병합하여 덮어쓰지 않습니다.
그 결과, 프로덕션의 우선순위 필드는 다음과 같은 선택지를 포함하게 됩니다:
낮음, 중간, 높음, 매우 낮음, 보통, 매우 높음.
결과
두 환경의 선택지가 결합되어 필드에 추가적인 값이 생기며, 이는 의도한 변경 사항과 일치하지 않을 수 있습니다.
데이터 무결성을 유지하기 위해 부모-자식 구성을 함께 동기화
프로덕션에서의 초기 설정
프로덕션에서는 위치 계층 구조가 있습니다:
북미 → 미국 → 캘리포니아 → 샌프란시스코.
샌드박스에서 새로운 구성 생성
샌드박스에서는 새로운 독립 위치를 샌프란시스코로 생성하며, 상위 계층 (캘리포니아, 미국, 또는 북미)와 연결하지 않습니다.
샌드박스를 프로덕션과 동기화
동기화 중에 Freshservice는 샌드박스의 샌프란시스코 위치를 새로운 별도의 항목으로 처리합니다.
프로덕션에서는 새로운 독립 위치 샌프란시스코 기존 계층적 위치(북아메리카 → 미국 → 캘리포니아 → 샌프란시스코)와 함께 생성됩니다.
결과
이로 인해 데이터 중복이 발생하며, 이제 두 개의 샌프란시스코 위치가 존재합니다:
기존 계층 아래 하나.
독립된 위치로 하나.
동기화 문제를 피하기 위한 모범 사례
구성 이름 변경 피하기: 구성을 삭제하고 다시 생성하는 것을 피하고, 대신 두 환경에서 구성 이름을 일관되게 유지하여 데이터 무결성을 유지하십시오.
수동 업데이트: 이름 변경이 필요할 경우, 프로덕션에서 구성을 수동으로 업데이트하여 일관성을 유지하십시오.
동기화 전 검토: 항상 두 환경의 구성을 검토하여 잠재적 충돌을 식별하십시오.
이 가이드라인을 따르면 동기화 오류를 최소화하고 샌드박스와 프로덕션 간의 원활한 전환을 보장할 수 있습니다.