사용자 도움말 > 변경 패키지의 작업 단위 그룹화 > 변경 패키지 다시 동기화 개요 > 변경 패키지 다시 동기화와 함께 전파 변경 패키지 사용
  
변경 패키지 다시 동기화와 함께 전파 변경 패키지 사용
다른 변경 패키지를 사용하여 변경 패키지 다시 동기화 작업에 의한 모든 멤버 변경 내용을 기록할 수 있습니다. 이 용도로 사용되는 변경 패키지를 전파 변경 패키지라고 합니다.
* 
관리자가 변경 패키지를 필수로 설정한 경우라도 변경 패키지 다시 동기화 작업에 대해 전파 변경 패키지를 지정할 필요는 없습니다.
사용자가 전파 변경 패키지를 생성하는 것은 아닙니다. 사용자는 일반 변경 패키지를 생성하고, 전파 정보는 변경 패키지 다시 동기화 작업 중에 변경 패키지를 지정할 때 변경 패키지에 기록됩니다. 변경 내용 격리의 제어 수준을 최고로 높이려면 빈 전파 변경 패키지로 시작하는 것이 좋습니다. 전파 변경 패키지에 이전 엔트리가 포함되어 있지 않으면 해당 변경 내용과 구체적으로 관련된 엔트리만 추가됩니다.
전파 변경 패키지는 수행된 모든 멤버 및 하위 프로젝트 변경 내용으로 채워지고, 다시 동기화의 결과로서 전파된 변경 패키지로 채워집니다. 원하지 않는 멤버 변경 내용을 무시할 수 있고, 해결된 병합 충돌을 전파 변경 패키지에 추가할 수 있습니다. 또한 체크 아웃, 이동, 이름 바꾸기, 멤버 개정 업데이트 또는 하위 프로젝트 생성 같은 Windchill RV&S 명령을 사용하여 필요에 따라 전파 변경 패키지에 엔트리를 추가할 수 있습니다.
모든 변경 내용이 완료된 후, 프로젝트 업데이트를 위해 전파 변경 패키지가 제출될 수 있습니다.
* 
또한 멤버 개정을 업데이트하지 않고 전파 변경 패키지를 제출할 수 있습니다. 그러면 빌드마스터가 소프트웨어 빌드 시점에 전파 변경 패키지를 적용합니다.
전파 변경 패키지의 엔트리는 다시 동기화된 변경 패키지의 상응하는 엔트리를 대체합니다. 따라서 분기에서 병합을 수행하고 결과를 전파 변경 패키지에 체크 인하는 경우, 그에 따른 개정은 분기에 있을 수 있는 나열된 변경 패키지의 모든 엔트리를 대체합니다.
전파 변경 패키지 사용의 이점
전파 변경 패키지를 사용하면 또 다시 변경 패키지 다시 동기화 명령을 실행하고 오류 또는 병합 충돌을 해결해야 하는 번거로움 없이 다른 개발자가 변경 패키지의 동일한 세트를 적용할 수 있습니다.
전파 변경 패키지는 빌드마스터가 작업을 완료하는 데 도움을 준다는 면에서도 유용합니다. 변경 패키지 적용 작업이 실패한 경우 개발자는 동일한 변경 패키지에 대해 변경 패키지 다시 동기화 명령을 사용하고, 종속성 및 필요한 병합을 식별하고, 모든 필수 변경 내용을 단일 전파 패키지에 포함할 수 있습니다.
전파 변경 패키지를 사용하면 긴 시간이 걸릴 수 있는 하나의 대규모 변경 패키지 다시 동기화 작업을 수행하는 대신 변경 패키지 다시 동기화 명령을 반복적으로 사용해 프로젝트 변경 내용을 수집함으로써 개발 경로 간에 점진적으로 변경 내용을 전파할 수 있습니다.
전파 변경 패키지를 사용하는 경우, 적용된 변경 패키지가 종속된 변경 패키지 중 이전의 변경 패키지 다시 동기화 작업을 통해 프로젝트에 이미 적용된 변경 패키지는 백필 목록에 나타나지 않습니다. 이미 적용된 변경 패키지에 대한 경고 메시지가 나타납니다.
전파 변경 패키지를 적용하기 위해 변경 패키지 다시 동기화가 사용될 수 있지만, 결과가 항상 수용할 만한 것은 아니라는 점에 유의해야 합니다. 예를 들어 버그 수정 사항이 기존 프로젝트 멤버에 있으면 해당 멤버에 대한 아카이브가 프로젝트에 이미 있는 것입니다. 따라서 변경 패키지 다시 동기화는 분기에 있는 수정된 멤버를 추가하게 됩니다. 이 추가적인 분기는 해당 프로젝트에서 수용되지 못할 수 있습니다.
전파 변경 패키지 사용의 예
abcBusiness 회사에는 2개의 개발 팀이 있습니다.
주 릴리스 주기에 맞춰 새 기능 및 소프트웨어를 개발하는 제품 팀
릴리스된 소프트웨어를 유지 관리하고 고객에 의해 확인된 버그를 해결하는 유지 보수 개발 팀
제품 팀(PT)은 주 개발 경로에서 새 기능 및 설계를 구현합니다.
유지 보수 개발 팀(MDT)은 릴리스 2.0을 위한 파생 개발 경로에서 작업하며, 새로 릴리스된 제품에 있는 모든 문제를 해결합니다. 이 팀의 기본 목적은 릴리스 2.0a에 대한 버그 수정 사항을 생성하는 것입니다. MDT의 작업 프로세스는 다음과 같습니다.
고객에 의해 버그가 보고됩니다.
버그에 대한 변경 패키지가 생성됩니다. 이 경우 컨테이너 ID는 1204입니다. 워크플로가 사용하도록 설정되어 항목이 생성되고, 생성한 변경 패키지와 연결됩니다.
문제를 해결할 MDT 개발자가 지정됩니다.
MDT 개발자가 변경 패키지를 생성합니다.
MDT 개발자가 필요에 따라 변경하고 코드를 테스트합니다.
MDT 개발자가 수정된 파일을 파생 프로젝트에 다시 체크 인하여 파일이 변경 패키지 1204:1과 연결되도록 합니다.
이 경우, MDT 개발자의 모든 작업은 이제 파생 개발 경로에 체크 인되고 릴리스 2.0a의 일부가 됩니다. 한편, MDT 버그 수정 작업은 다음 제품 릴리스에 통합될 수 있도록 주 개발 경로로 다시 전달되어야 합니다. PT 개발자는 버그 수정 사항을 처리하는 변경 내용을 선택하고 이러한 변경 내용을 샌드박스에 적용해야 합니다. 변경 패키지 다시 동기화 명령은 새 수정 사항을 적용하기 위한 최상의 옵션입니다.
PT 개발자는 동일한 항목에 대해 두 번째 변경 패키지 1204:2를 생성합니다. 두 번째 변경 패키지는 "주 개발 경로에 수정 사항이 적용됨"이라는 요약을 포함합니다. PT 개발자는 변경 패키지 다시 동기화 명령을 시작하고, 주 개발 샌드박스를 선택하며 이 항목에서 첫 번째 변경 패키지인 1204:1을 선택합니다. 두 번째 변경 패키지 1204:2는 전파 변경 패키지로 사용됩니다.
모든 병합 충돌이 해결된 후에 개발자는 전파 변경 패키지를 제출하고, Windchill RV&S는 참조된 변경 패키지에서 변경 내용을 적용합니다.
이제 버그 수정 사항이 주 개발 경로 및 파생 개발 경로 모두에서 처리되었으며, 이를 통해 해당 문제는 릴리스 2.0a 및 향후의 주 제품 릴리스에서 해결됩니다.