정상적인 모델 기반 앱 양식 ALM 유지
이 문서에서는 모델 기반 앱 솔루션에서 양식을 사용자 지정하기 위해 정상적인 ALM(애플리케이션 수명 주기 관리)을 구현하고 실행하는 방법에 대한 다양한 시나리오에 관한 정보를 제공합니다.
다음 섹션에서는 양식 병합이 작동하는 방식과 사용자 지정을 유지 관리하는 방법에 대해 설명합니다. 모델 기반 앱 양식에 대한 성공적인 ALM 유지를 위한 권장 사항이 포함된 기본 개발 시나리오는 이어지는 각 섹션에서 자세히 다룹니다. 모든 시나리오에는 솔루션 또는 모델 기반 앱을 업데이트할 때 적절한 ALM 프로세스를 구현하는 데 도움이 되는 단계가 포함되어 있습니다.
이 시나리오에서 정상적인 ALM을 구현하려면 다음 단계를 따르세요.
- 개발 환경에서 FormA라는 이름의 새 양식을 만들고 양식에 사용자 지정을 수행합니다.
- 개발 환경에서 새 솔루션(아래 그림에서 Solution A)를 만듭니다. 이는 관리되지 않는 솔루션이 되며 새 양식을 추가합니다. 솔루션을 관리형으로 내보냅니다. 이 단계는 양식의 전체 FormXml을 내보냅니다.
- 테스트 환경의 2단계에서 관리형 솔루션를 가져오면 테스트 환경에 FormA가 생성됩니다. 아래 다이어그램에서는 테스트 환경에 FormA가 생성되고 양식의 UI가 Field1과 Field2로 표시되며 양식에 Solution A가 추가되어 있습니다.
- 새로운 개발(소스) 환경을 사용하여 1단계에서 만든 양식을 추가로 사용자 지정할 경우 2단계에서 만든 Solution A를 가져오고 사용 중인 개발 인스턴스의 FormA가 관리형 상태인지 확인합니다. 아래 다이어그램과 같이 관리되는 Solution A를 개발 환경에서 가져오고 양식이 사용자 지정되어 활성 사용자 지정을 생성합니다. 그런 다음 FormA가 관리되지 않는 새로운 솔루션(다이어그램에서 Solution B)에 추가되고 개발 환경에서 관리형 솔루션으로 내보내집니다. 이 단계는 양식의 차동(diff) FormXml을 내보냅니다.
- 테스트 환경의 4단계에서 관리형 솔루션(Solution B)을 가져옵니다. 아래 다이어그램과 같이 Solution B는 새 Field3을 FormA에 추가하고 Solution A에 의해 추가된 Field2를 제거합니다. 이제 테스트 환경의 양식에 대한 UI가 병합 후에 양식에서 Field2가 아닌 Field3과 Field1을 표시합니다.
아래 다이어그램에서 볼 수 있듯이 기본 솔루션(Solution A)이 관리되지 않는 상태인 개발 환경에서 여러 관리형 솔루션을 만들기 위한 정상적인 ALM 사례가 아닙니다. 이는 다른 비관리형 솔루션(Solution B)을 생성할 때 관리되지 않는 양식의 경우 위의 유효한 시나리오에 표시된 대로 FormXml을 diff FormXml 대신 전체 FormXml로 내보내기 때문입니다. 이후에는 열 제거와 같은 변경 사항이 적용되지 않습니다.
이 시나리오에서 정상적인 ALM을 구현하려면 다음 단계를 따르세요.
개발 환경에서 FormA라는 이름의 새 양식을 만들고 양식에 사용자 지정을 수행합니다.
솔루션(아래 그림에서 Solution A)를 만듭니다. 이는 관리되지 않는 솔루션이 되며 새 양식을 추가합니다. 솔루션을 관리형으로 내보냅니다. 이 단계는 양식의 전체 FormXml을 내보냅니다.
테스트 환경의 2단계에서 관리형 솔루션를 가져오면 테스트 환경에 양식이 생성됩니다. 아래 다이어그램에서는 테스트 환경에 FormA가 생성되고 양식의 UI가 Field1과 Field2로 표시되며 양식에 Solution A가 추가되어 있습니다.
패치를 사용하여 1단계에서 만든 양식을 추가로 사용자 정의할 때 Solution A가 관리되지 않는 상태인 동일한 환경을 사용하고 솔루션에 대한 패치를 만들어 양식을 사용자 지정합니다. 다음으로 패치를 관리형 솔루션으로 내보냅니다. 이 단계는 양식의 전체 formXml을 내보냅니다.
테스트 환경의 4단계에서 관리형 패치 솔루션을 가져옵니다. 아래 다이어그램과 같이 Solution A 패치는 새로운 Field3을 FormA에 추가하고 Solution A에 의해 추가된 Field2를 제거합니다.
참고
풀 formXml을 포함하는 패치는 항상 패치가 생성된 기본 레이어와 비교되며 기본 패치와 현재 패치 사이의 중간 패치는 무시합니다. 결과적으로 Field2은 기본 레이어 솔루션 A에 존재하므로 제거되며 제거가 감지됩니다. 반면 Field3은 이 패치 솔루션에 의해 추가되었으며 후속 패치에서 제거할 수 없습니다. 따라서 패치 솔루션을 통해 추가된 필드는 본질적으로 가산적입니다.
업그레이드를 사용하여 1단계에서 만든 양식을 추가로 사용자 정의할 때 Solution A가 관리되지 않는 상태인 동일한 환경을 사용하고 Solution A를 복제하여 업그레이드 솔루션을 만들고 양식을 사용자 지정합니다. 그런 다음 Solution A 업그레이드를 관리형 솔루션으로 내보냅니다. 이 단계는 양식의 전체 FormXml을 내보냅니다.
테스트 환경의 6단계에서 관리형 Solution A를 가져옵니다. 아래 다이어그램과 같이 Solution A 업그레이드는 새 Field4를 FormA에 추가하고 Solution A에 의해 추가된 Field2를 제거합니다. 이제 테스트 환경의 양식에 대한 UI가 양식에서 Field1, Field3 및 Field4를 표시하지만 가져오기에서 양식이 병합된 후 Field2가 제거됩니다.
이 시나리오에서 정상적인 ALM을 구현하려면 다음 단계를 따르세요.
- 이 예에서는 개발 환경에서 FormB라는 기존 관리형 양식을 편집하고 양식에 사용자 지정을 수행합니다. 솔루션 A는 개발 환경의 양식에 이미 설치된 관리형 솔루션입니다.
- 새 솔루션(아래 그림에서 Solution B)를 만듭니다. 이는 관리되지 않는 솔루션이 되며 FormB를 추가합니다. 솔루션을 관리형으로 내보냅니다. 이 단계는 양식의 차동(diff) FormXml을 내보냅니다.
- 테스트 환경의 2단계에서 관리형 솔루션를 가져오면 양식에 대한 두 번째 솔루션 레이어가 생성됩니다. 아래 다이어그램과 같이 FormB는 테스트 환경의 Solution A와 Solution B에서 병합된 변경 사항을 가져오고 양식에 대한 UI가 Solution B에 의해 제거된 Field2가 아닌 Field1과 Field3을 양식에 표시합니다.
- 새 관리형 솔루션을 사용하여 1단계에서 사용자 지정한 양식을 추가로 사용자 지정할 때 관리형 상태에 FormB이 있는 새 개발 환경을 사용해야 합니다. 아래 다이어그램과 같이 새 개발 환경에서 Solution A와 Solution B가 가져오기됩니다. FormB 는 활성적인 사용자 정의를 생성하여 사용자 정의한 후 새 솔루션(다이어그램의 솔루션 C )에 추가하고 관리형 솔루션로 내보낼 수 있습니다.
- 테스트 환경의 4단계에서 관리형 Solution C를 가져옵니다. 아래 다이어그램과 같이 Solution C는 새 Field4를 FormB에 추가하고 Solution B에 의해 추가된 Field3을 제거합니다. 이제 테스트 환경의 양식에 대한 UI가 양식에서 Field2와 Field3이 아닌 Field1과 Field4를 표시합니다.
아래 다이어그램에서 볼 수 있듯이 동일한 양식에 대해 생성한 다른 관리형 솔루션이 있는 개발 환경에서 여러 관리형 솔루션을 만들기 위한 정상적인 ALM 사례가 아닙니다. Solution B는 관리되지 않는 상태입니다. FormB에 대해 다른 비관리형 솔루션(Solution C)을 생성하는 경우 위 시나리오의 4단계에 표시된 대로 FormXml을 diff FormXml로 내보냅니다. 그러나 FormB는 Solution B의 변경 사항도 포함하며, 새로운 변경 사항에 의해 덮어써집니다.
예를 들어 아래 다이어그램에서 볼 수 있듯이Field3이 Solution B의 FormB에 추가됩니다. 하지만 고나리되지 않는 상태의 Solution B를 사용하여 이 환경에 새로운 Solution C를 만들고 Field3을 제거하면 Field3이 개발 환경에서도 제거됩니다. 솔루션을 내보낼 때 Field3 은 diff FormXml에서 추적되지 않습니다. 이 열을 추가하고 제거하는 변경 사항은 동일한 활성 레이어에서 이루어졌기 때문입니다. 즉, 테스트 환경에서 관리형 Solution C를 가져오면 diff FormXml이 이를 제거된 것으로 기록하지 않기 때문에 양식에서 Field3을 계속 렌더링합니다(위의 정상적인 양식 ALM 시나리오의 5단계에서 제거된 것처럼). 이러한 방식으로 양식 사용자 정의를 수행하면 개발 환경이 테스트 환경과 일치하지 않게 됩니다.
이 시나리오에서 정상적인 ALM을 구현하려면 다음 단계를 따르세요.
이 예에서는 개발 환경에서 FormB라는 기존 관리형 양식을 사용자 지정하고 양식에 사용자 지정을 수행합니다. Solution A는 개발 환경의 양식에 이미 설치된 관리형 솔루션입니다.
솔루션(Solution B)를 만듭니다. 이는 관리되지 않는 솔루션이 되며 FormB를 추가합니다. 솔루션을 관리형으로 내보냅니다. 이 단계는 양식의 diff FormXml을 내보냅니다.
테스트 환경의 2단계에서 관리형 Solution B를 가져오면 양식에 대한 두 번째 솔루션 레이어가 생성됩니다. 아래 다이어그램에서 FormB는 테스트 호나경에서 Solution A와 Solution B로부터 병합된 변경 사항을 가져옵니다. 또한 FormB의 UI는 Solution B에 의해 제거된 Field2가 아닌 Field1과 Field3을 양식에 표시합니다.
패치 솔루션을 사용하여 1단계에서 사용자 정의한 양식을 추가로 사용자 정의하면 1단계와 동일한 개발 환경을 사용할 수 있습니다. 여기서 Solution B는 관리되지 않는 상태로 존재합니다. 아래 다이어그램과 같이 Solution A는 관리되는 상태이며 Solution B는 관리되지 않는 상태입니다. 양식은 추가로 사용자 정의되며 Solution B에 대해 패치를 만들어 이 솔루션에 양식을 추가하고 관리되는 패치 솔루션으로 내보냅니다. 이 단계는 diff FormXml을 내보냅니다.
테스트 환경의 4단계에서 관리형 패치 Solution B를 가져옵니다. 아래 다이어그램과 같이 Solution B 패치는 새로운 Field4를 FormB에 추가하고 Solution B에 의해 추가된 Field3을 제거합니다.
참고
패치는 본질적으로 추가적이며 양식에서 열과 같은 구성 요소를 제거할 수 없습니다. 따라서 Field3은 양식에서 제거되지 않습니다. 이제 테스트 환경의 양식에 대한 UI가 Field2가 아닌 Field1, Field3 및 Field4를 양식에 표시합니다.
업그레이드를 사용하여 1단계에서 만든 양식을 추가로 사용자 정의할 때 Solution B가 관리되지 않는 상태인 동일한 환경을 사용하고 Solution B를 복제하여 업그레이드 솔루션을 만들고 FormB를 사용자 지정합니다. 업그레이드를 관리형 솔루션으로 내보냅니다. 이 단계는 양식의 diff FormXml을 내보냅니다.
테스트 환경의 6단계에서 관리형 Solution B 업그레이드 솔루션을 가져옵니다. 아래 다이어그램과 같이 Solution B 업그레이드는 새 Field5를 FormB에 추가하고 Solution B에 의해 추가된 Field3을 제거합니다. 이제 테스트 환경의 양식에 대한 UI가 양식에서 Field2와 Field3이 아닌 Field1, Field4 및 Field5를 표시합니다.
이 시나리오에서 정상적인 ALM을 구현하려면 다음 단계를 따르세요.
- 개발 환경 1에서 새로운 FormA를 만들고 양식에 사용자 지정을 수행합니다.
- 솔루션(아래 그림에서 Solution A)를 만듭니다. 이는 관리되지 않는 솔루션이 되며, 새 양식을 추가합니다. 솔루션을 비관리형으로 내보냅니다. 이 단계는 양식의 전체 FormXml을 내보냅니다.
- 개발 환경 2에서 2단계의 관리되지 않는 솔루션을 가져오면 개발 환경 2에 양식이 생성됩니다. 아래 다이어그램에서는 FormA가 생성되고 양식의 UI가 Field1과 Field2로 표시되며 양식에 Solution A가 추가되어 있습니다.
- 개발 환경 2에서 양식을 추가로 사용자 정의하여 환경에서 Field3이라는 새로운 열 추가와 같은 활성 사용자 지정을 만듭니다. FormA 이제 Field1, Field2 및 이 표시됩니다. 필드3.
- 개발 환경 1에서 Field4도 추가하여 양식을 추가로 사용자 정의합니다. 이제 개발 환경 1에서 양식에 대한 UI가 Field1, Field2 및 Field4를 표시합니다.
- 5단계의 변경 사항과 함께 관리되지 않는 Solution A를 내보냅니다. 이 단계는 양식의 전체 FormXml을 내보냅니다.
- 개발 환경 2의 6단계에서 비관리형 Solution A 업그레이드를 가져옵니다. 가져오는 솔루션에 FormA에 대한 전체 FormXml이 포함되어 있으므로 개발 환경 1에 적용된 활성 사용자 지정을 덮어씁니다. 따라서 이제 양식에서는 개발 환경 1에서 완료된 추가 활성 사용자 지정이었던 Field3이 아닌 Field1, Field2 및 Field4를 표시합니다. 이 동작은 양식에 대한 전체 FormXml이 있는 관리되지 않는 솔루션 가져오기에서 발생합니다.
이 시나리오에서 정상적인 ALM을 구현하려면 다음 단계를 따르세요.
- 이 예에서는 개발 환경 1에서 FormB라는 기존 양식을 사용자 지정합니다. 그런 다음 양식에 사용자 정의를 수행합니다.
- 솔루션(아래 다이어그램에서 Solution B)를 만듭니다. 이는 관리되지 않는 솔루션이 되며 FormB를 추가합니다. 솔루션을 비관리형으로 내보냅니다. 이 단계는 양식의 diff FormXml을 내보냅니다.
- 개발 환경 2의 2단계에서 비관리형 솔루션을 가져오면 양식에 대한 두 번째 솔루션 레이어가 생성됩니다. FormB UI는 양식 병합 후 Field1, Field2 및 Field3을 표시합니다.
- 개발 환경 2에서 양식을 추가로 사용자 정의하여 환경에서 Field4라는 새로운 열 추가와 같은 활성 사용자 지정을 만듭니다. FormB 에 이제 Field1, Field2, Field3, Field4가 표시됩니다.
- 개발 환경 1에서 Field5라는 새 열을 추가하여 양식을 추가로 사용자 정의합니다. 이제 개발 환경 1에서 양식에 대한 UI가 Field3 및 Field5를 표시합니다.
- 5단계의 변경 사항과 함께 관리되지 않는 Solution B를 내보냅니다. 이 단계는 양식의 diff FormXml을 내보냅니다.
- 개발 환경 2의 6단계에서 비관리형 Solution B 업그레이드를 가져옵니다. 가져오는 솔루션에 FormB에 대한 diff FormXml이 포함되어 있으므로 개발 환경 1에 적용된 활성 사용자 지정과 병합합니다. 따라서 이제 양식에서는 Field1, Field2, Field3, Field4 및 Field5를 표시합니다. 이 동작은 양식에 대한 diff FormXml이 있는 관리되지 않는 솔루션 가져오기에서 발생합니다.
- 관리되지 않는 솔루션으로 diff FormXml을 가져왔지만 7단계의 양식 병합이 원하는 대로 되지 않고 개발 환경 2에 적용된 활성 사용자 지정을 덮어쓸 수 있도록 하려는 경우 FormB의 활성 레이어를 제거합니다. 추가 정보: 관리되지 않는 레이어 제거.
- 5단계의 변경 사항과 함께 관리되지 않는 Solution B를 내보냅니다. 이 단계는 양식의 diff FormXml을 내보냅니다.
- 개발 환경 2의 9단계에서 비관리형 Solution B 업그레이드를 가져옵니다. 개발 환경 2의 양식에 대한 활성 레이어가 없기 때문에(8단계 참조) FormB에 대한 diff FormXml을 가져오는 경우에도 관리되지 않는 Solution B의 모든 변경 사항을 가져옵니다. 따라서 이제 양식에서는 Field1, Field2, Field3 및 Field5만 표시합니다. 이 동작은 양식에 대한 diff FormXml이 있는 관리되지 않는 솔루션 가져오기에서 발생합니다. 여러 개발 환경에서 기존 양식에 대한 관리되지 않는 솔루션 및 사용자 지정 유지 관리 시나리오의 7단계와 동일한 결과입니다.
내보낸 모든 솔루션 패키지에는 customizations.xml 파일이 포함되어 있습니다. 양식이 솔루션에 포함될 때마다 관련 양식 정의가 customizations.xml 파일의 FormXml 섹션 내에 존재합니다. FormXml은 전체 또는 차동(diff)일 수 있습니다.
관리되지 않는 상태의 양식에 대한 솔루션을 내보낼 때 가져오는 FormXml은 전체 FormXml이라고 합니다. 전체라는 것은 전체 양식 정의가 포함되어 있음을 의미합니다. 새 양식을 만들고 내보낼 때 내보내는 환경의 양식이 관리되지 않는 상태이며 만들기 상태이므로 양식은 항상 전체 FormXml이 됩니다. 이 동일한 환경에서 추가 솔루션을 내보내면 해당 솔루션에도 전체 FormXml이 포함됩니다. solutionaction
특성은 diff FormXml을 나타내므로 내보내는 솔루션의 customization.xml 파일에 있는 전체 FormXml에는 어떤 solutionaction
특성도 포함되지 않습니다.
관리되는 상태의 양식에 대한 솔루션을 내보낼 때 가져오는 FormXml은 차동 또는 diff FormXml이라고 합니다. Diff는 FormXml에 전체 양식 정의가 아니라 해당 환경의 활성 사용자 지정에서 수행된 변경 사항만 포함되어 있음을 의미합니다. 기존 관리 양식을 사용자 정의하고 내보낼 때 양식에 수행된 활성 변경 사항만 포함되기 때문에 양식은 항상 diff FormXml이 됩니다. 내보내는 솔루션의 customization.xml 파일에 있는 diff FormXml에는 solutionaction
특성이 포함되며 추가됨, 제거됨, 수정됨과 같은 병경 내용을 정의합니다.
Diff FormXml을 사용하면 솔루션이 앱에 필요한 변경 사항만 표현하고 다른 계층의 변경 사항으로 인한 영향을 덜 받을 수 있습니다. Diff FormXml은 또한 솔루션의 부피를 줄이고 더 빠르게 가져올 수 있도록 도와줍니다.