Salesforce 릴리스 트레인: 릴리스 관리에 대한 실용적인 접근 방식
게시 됨: 2022-03-11릴리스 관리는 이름에서 알 수 있듯이 다양한 단계와 환경을 통해 소프트웨어 빌드를 관리, 계획, 스케줄링 및 제어하는 프로세스입니다. 소프트웨어 릴리스 테스트 및 배포 포함(Humble & Farley, 2011).
그것은 그 자체로 꽤 큰 주제이며 개발 팀과 다양한 반복을 시도하고 비즈니스 요구 또는 기능 릴리스를 일치시킴으로써 시간이 지남에 따라 완성될 수 있습니다. 우리는 메타데이터 관리, CI 구축 및 조직의 릴리스 트레인 관리를 위한 샌드박스 관리의 업계 관행을 다루려고 노력할 것입니다.
그러나 릴리스 트레인이란 무엇입니까?
릴리스 트레인은 점진적이고 예측 가능한 기능 제공 기술입니다. 개발자는 개발 환경에서 변경된 사항을 적용하고 프로덕션에 배포하기 위한 공식 프로세스를 설정해야 합니다.
릴리스 트레인은 크게 세 부분으로 나눌 수 있습니다.
- 메타데이터 관리
- 지속적인 통합 빌드
- 샌드박스 관리
메타데이터 관리
메타데이터는 다른 데이터에 대한 정보를 제공하는 데이터입니다. Salesforce는 Metadata API 를 통해 풍부하고 강력한 메타데이터 모델을 제공합니다. 애플리케이션 메타데이터는 조직의 소스 코드 및 구성에 대한 프로그래밍 방식 액세스를 제공하는 방법 집합을 설명하고 포함합니다.
Metadata API는 Salesforce에서 사용자 정의를 관리하는 가장 좋은 방법입니다. create , read , update 및 delete 메소드를 지원합니다. 변경 세트, Force.com IDE 및 Ant 마이그레이션 도구를 사용하여 한 조직에서 다른 조직으로 메타데이터를 마이그레이션할 수 있습니다. 모두 API를 통해 마이그레이션을 제공하기 때문입니다.
각 도구에는 고유한 장점이 있으며 하나를 선택할 때 고려해야 할 몇 가지 사항이 있습니다.
표 1: 메타데이터 마이그레이션을 위한 도구 비교
| 세트 변경 | Force.com IDE | 개미 마이그레이션 도구 |
|---|---|---|
| 변경 세트는 표준 Salesforce UI를 통해 구성 요소를 배포하는 방법입니다. | Force.com IDE(Eclipse)는 주로 Apex 개발용이지만 배포 목적으로 사용할 수 있습니다. | Ant Migration은 환경 간 변경/메타데이터 마이그레이션 전용의 강력한 명령줄 도구입니다. |
| 일반적으로 소수의 구성 요소 마이그레이션에 사용됩니다. | 개발자는 일반적으로 테스트 또는 스테이징 환경으로 변경 사항을 마이그레이션하기 위해 IDE를 사용합니다. | Ant 마이그레이션은 대규모 페이로드 마이그레이션에 사용되며 Salesforce Metadata API에 대한 고급 지식이 필요합니다. |
| 조직 간의 연결을 수동으로 설정해야 하므로 자동화된 배포에 적합하지 않습니다. | 모든 조직에 배포하는 데 사용할 수 있지만 오류가 발생하기 쉬운 몇 가지 수동 단계가 필요합니다. | 자동 배포는 매우 쉽게 예약할 수 있습니다. |
| 관리자용입니다. | 코드 개발이 주요 용도이므로 Salesforce 개발자를 대상으로 합니다. | DevOps 엔지니어를 대상으로 합니다. |
| 종속성을 추가하는 것은 매우 쉽고 사용자 친화적입니다. | 종속성을 추가하는 것은 포인트 앤 클릭 UI를 제공하기 때문에 다소 쉽습니다. | 일반적으로 종속성 누락으로 인해 배포가 실패합니다. |
| 파괴적인 변경을 허용하지 않습니다. | 파괴적인 변경 세트를 허용하지만 프로세스가 상당히 지루합니다. | 파괴적인 변경 세트를 허용합니다. |
Metadata API는 Force.com 플랫폼에서 변경 사항을 개발하고 마이그레이션할 때 목적을 달성하는 데 탁월합니다. 그러나 약간의 문제가 있습니다. 모든 Salesforce 메타데이터가 Metadata API에서 지원되는 것은 아닙니다. 공식 문서는 지원되지 않는 구성 요소 목록을 제공합니다.
조직에서 Metadata API에서 지원하지 않는 변경을 수행하는 경우 대상 조직에서 이러한 변경을 수동으로 복제해야 합니다. 이러한 변경 사항을 추적하는 가장 좋은 방법은 스프레드시트입니다. 이 접근 방식을 사용해야 하는 경우 한 사람이 이러한 변경을 수행하고 추적하는 것이 좋습니다.
다음은 스프레드시트에서 이러한 변경 사항을 추적하는 데 사용할 수 있는 일반적인 열 목록입니다.
- 구성 요소 이름
- 구성 요소 유형
- 소유자 변경
- 기능 설명
- 기능 매핑
- 다른 구성 요소와의 종속성
- 검토자/검토자 이름
- URL
- 조직 이름/ID
- 기타 의견
버전 관리 및 지속적 통합
변경 사항을 프로덕션으로 마이그레이션하는 것은 테스트 및 스테이징 환경에서 변경 사항을 적용하는 반복일 뿐이므로 원활한 프로세스여야 합니다. 그래도 항상 상황이 악화될 가능성이 있으므로 대체 계획이 필요합니다. 조직의 메타데이터를 백업하는 것이 매우 중요하며 이것이 버전 제어 및 CI 빌드 의 목적입니다.
버전 관리는 모든 조직에서 절대적으로 필요합니다. 이를 통해 개발자는 협력적이고 효율적이며 안전한 방식으로 작업할 수 있습니다. 다중 개발자, 다중 샌드박스 코드 개발 및 마이그레이션을 관리하는 것은 Salesforce의 과제입니다. Salesforce에는 릴리스 및 유지 관리에 대한 자체 일정도 있습니다. 이러한 업데이트는 새로운 기능을 제공하지만 CI 빌드를 손상시킬 수 있는 메타데이터 API의 변경을 도입할 수 있습니다. 따라서 개발자가 서로의 변경 사항을 덮어쓰는 상황을 제외하고 버전 제어는 롤백 전략을 구축하는 데 도움이 됩니다. 애플리케이션이 Force.com에서 실행될 때 롤백 전략이 있어야 합니다.
다음 흐름도는 버전 관리 및 CI의 실제 구조를 보여줍니다. 다이어그램이 나타내는 내용에 대한 빠른 설명을 제공하려고 합니다.
- 개발자는 버전 관리 시스템에서 변경 사항을 확인합니다.
- CI Server/Jenkins는 CI 샌드박스에 최신 빌드를 배포하고 테스트 클래스를 실행합니다.
- 2단계의 배포가 성공하면 변경 사항이 QA 분기에 병합됩니다.
- 그런 다음 CI는 QA 분기의 최신 커밋을 QA 샌드박스로 배포합니다.
- QA가 테스트 실패로 인해 변경 사항을 거부하는 경우 QA가 변경 사항을 지울 때까지 1~3단계를 다시 수행해야 합니다.
- 변경 사항이 QA 테스트를 통과하면 변경 사항이 마스터 분기에 병합됩니다.
- 마스터 분기의 최신 변경 사항이 마스터 샌드박스에 배포됩니다.
조직의 필요에 따라 더 많은 지점을 추가하도록 선택할 수 있습니다. 그러나 위의 구조는 중간에서 엔터프라이즈 수준의 개발 구조에 적합합니다.
샌드박스 관리
조직의 DevOps 프로세스를 최대한 활용하려면 샌드박스 구조를 설정하는 것이 매우 중요합니다. 자세히 알아보기 전에 Salesforce에서 제공하는 다양한 유형의 샌드박스에 대해 알아보겠습니다.
샌드박스는 프로덕션 메타데이터의 거의 정확한 사본입니다. 샌드박스는 일반적으로 개발, 테스트, 준비 및 교육 목적으로 사용됩니다. 샌드박스에는 4가지 유형이 있으며 샌드박스를 선택할 때 한 가지를 충분히 고려해야 합니다. 전체 복사 샌드박스에는 많은 비용이 들 수 있습니다!
다음은 다양한 샌드박스에 대해 Salesforce에서 시행하는 제한에 대한 표입니다.
표 2: 한계 비교
| 개발자 | 개발자 프로 | 부분 복사 | 전체 복사 | |
|---|---|---|---|---|
| 생산 데이터 | 아니요 | 아니요 | 네 | 네 |
| 데이터 저장고 | 200MB | 1GB | 5GB(객체당 10K 레코드) | 완전한 데이터 |
| 새로 고침 기간 | 1 일 | 1 일 | 5일 | 29일 |
가격만이 샌드박스의 유일한 차이점이 아님을 알 수 있습니다.
개발자 샌드박스에는 1일의 새로 고침 기간이 있어 개발에 적합하지만 200MB의 데이터만 수용할 수 있고 프로덕션 데이터는 수용할 수 없습니다. 정반대로 전체 복사 샌드박스에는 프로덕션 데이터의 정확한 복사본이 있습니다. 레코드 ID도 동일합니다. 그러면 테스트 및 준비에 적합할 수 있지만 새로 고침 기간이 29일이므로 전체 복사본 샌드박스에서 최신 프로덕션 메타데이터 및 데이터를 가져오기가 어렵습니다.
아래 표는 샌드박스 선택에 대한 경험적 규칙으로 사용됩니다.
표 3: 샌드박스 선택 사용 사례
| 개발자 | 개발자 프로 | 부분 복사 | 전체 복사 | |
|---|---|---|---|---|
| 개발 | 네 | 네 | 아니요 | 아니요 |
| 품질보증 | 네 | 네 | 네 | 아니요 |
| 통합 테스트 | 아니요 | 아니요 | 네 | 네 |
| 배치 데이터 테스트 | 아니요 | 아니요 | 네 | 네 |
| 훈련 | 아니요 | 아니요 | 네 | 네 |
| UAT | 아니요 | 아니요 | 네 | 네 |
| 부하 테스트 | 아니요 | 아니요 | 아니요 | 네 |
| 각색 | 아니요 | 아니요 | 아니요 | 네 |
| 사용자 교육 | 아니요 | 아니요 | 아니요 | 네 |
다음은 중간 규모 프로젝트에 채택된 일반적인 조직 구조입니다. 엔터프라이즈 수준 클라이언트의 경우 조직 구조가 더 복잡해지지만 대체로 아래 모델을 따릅니다.
Salesforce 개발은 일반적으로 개발자 샌드박스(빨간색)에서 수행되고 변경 사항은 일반적으로 개발자 프로 또는 부분 복사 샌드박스인 통합 샌드박스(녹색)로 이동됩니다. 그런 다음 여러 통합 샌드박스의 변경 사항이 부분 복사 샌드박스여야 하는 롤업 샌드박스(노란색)로 이동됩니다.
조직에 통합 테스트 및 부하 테스트를 수행해야 하는 타사 시스템과의 통합이 있는 경우 릴리스마다 변경되지 않는 안정적인 데이터 세트가 있어야 합니다. 따라서 전체 복사 또는 부분 복사 샌드박스를 사용하는 것이 좋습니다.
그런 다음 이러한 변경 사항은 테스트가 수행되는 통합 테스트 샌드박스로 이동됩니다. 그런 다음 변경 사항이 전체 복사 샌드박스여야 하는 스테이징 샌드박스로 이동됩니다. 모든 테스트 클래스는 배포 전에 실행됩니다. 배포가 문제 없이 발생하는지 확인하려면 배포 유효성 검사를 수행해야 합니다.
이 프로세스는 변경 사항이 여러 차례의 테스트와 한 쌍의 눈을 거쳤는지 확인하는 데 도움이 됩니다. 변경 사항을 개발, 테스트 및 배포하는 데 많은 시간이 필요하다는 큰 단점이 있습니다.
매우 자주 버그 수정이나 패치를 긴급히 수행해야 합니다. 이를 신속하게 처리하려면 작은 패치를 롤업 샌드박스에 직접 푸시하는 개발자 샌드박스를 유지해야 합니다.
앞서 언급했듯이 샌드박스는 프로덕션 메타데이터의 거의 정확한 복제본이지만 완전히는 아닙니다. 샌드박스에서 비활성화되는 구성 요소/기능의 공식 목록이 있습니다.
샌드박스를 새로 고칠 때 고려해야 할 또 다른 사항은 프로덕션 메타데이터와 데이터만 복사한다는 것입니다. 한 샌드박스에서 다른 샌드박스로 메타데이터를 복사하거나 메타데이터 구성(예: 무료 개발자 조직) 없이 빈 샌드박스를 만들 수 있는 방법이 없습니다. 이것은 때때로 실제 상황에서 도전이 됩니다. Salesforce는 이 문제를 해결할 계획을 가지고 있으며 이 기능은 곧 일반 공급될 수 있습니다.
또한 개발 또는 테스트 팀이 액세스할 수 없다고 생각하는 프로덕션에 일부 민감한 데이터가 있는 경우 전체 및 부분적으로 복사된 샌드박스에 대한 샌드박스 템플릿을 만들 수 있습니다.
배포 시 고려해야 할 사항
Salesforce 에코시스템에서 응용 프로그램 수명 주기 관리의 업계 관행을 다뤘습니다. 메타데이터 및 샌드박스 관리는 배포 패키지 및 페이로드를 생성하는 데 매우 중요한 역할을 합니다. 크고 복잡한 Salesforce 응용 프로그램의 경우 버전 제어는 메타데이터 변경 사항을 추적하는 동시에 롤백 전략을 만드는 데 도움이 됩니다.
샌드박스 관리는 크거나 복잡한 프로젝트에 매우 중요합니다. 그러나 샌드박스는 재정적 자원과 시간 면에서 Salesforce 에코시스템에서 비용이 많이 듭니다. 샌드박스 관리 전략을 수립하는 것은 릴리스 관리 프로세스에서 항상 중요합니다.
다음 배포 시 염두에 두면 좋을 몇 가지 추가 사항을 알려 드리겠습니다.
- 10,000개 파일 또는 39MB ZIP 파일만 한 번에 배포할 수 있습니다. 당연히 페이로드가 너무 크면 패키지를 여러 부분으로 나누어 배포해야 합니다.
-
request timeout오류로 인해 배포가 실패하는 경우 패키지에서 개체, 사용자 정의 필드 및 프로필을 제거해 보십시오. 이러한 구성 요소는 배포하는 데 시간이 더 오래 걸립니다. - 필드 유형이 변경되거나 역할 계층에 변경 사항이 있는 경우 데이터 재계산으로 인해 오랜 지연이 발생할 수 있으며 완료하는 데 약간의 시간이 필요합니다.
- Salesforce는 시스템의 사용자가 현재 사용 중인 모든 구성 요소를 잠급니다. 이 경우 배포를 시도하면 배포가 실패합니다.
이 개요가 다음 Salesforce 릴리스에 도움이 되기를 바랍니다.