3번째 챕터는 애플리커이션 수명 주기 및 개발 모델에 관한 내용이다.
1. 애플리케이션 수명 주기 관리 이해
-
릴리스 관리에 대한 기초 지식 학습
-
점점 더 복잡해지는 릴리스의 변경 사항 관리
-
보다 유연한 릴리스를 위해 패키지 개발 사용
1. 애플리케이션 수명 주기 관리 이해
학습목표
- 프로덕션 조직에서 직접 수행하는 것이 안전한 사용자 정의를 식별할 수 있습니다.
- 애플리케이션 수명 주기 관리를 정의할 수 있습니다.
Salseforce에서는 사용자에 요구를 충족 시키기 위해서 다양한 개발 도구와 프로세스를 제공한다. ALM(어플리케이션 수명 주기 관리) 이라고 하며 3가지 종류가 있다.
- 변경 집합 개발
- 조직 개발
- 패키지 개발
3가지 종류는 같은 개발 단계를 거치지만 변경 사항을 관리하는 방법이 각자 다르다. 변경 사항을 잘 인지하고 상황에 가장 적합한 모델을 선택할 수 있어야한다.
여기서는 이런게 있다 이정도만 설명 해주는거 같다.
다른 챕터 주제일 때 다시 다뤄야겠다.
프로덕션 조직에서 사용자 지정은 데이터에 영향을 미치지 않아 새 대시보드, 보고서 및 전자 메일, 템플릿 개발 같은 프로덕션 조직들을 안전하게 만들 수 있지만, 프로덕션에서 직접 수행한 특정 사용자 정의는 데이터가 삭제되거나 문제가 발생할 수 있다.
조직을 커스텀 할 때 가장 안전한 방법은 개발 전용 환경을 사용하는 것이다, 몇몇 변경 사항들은 개발 전용 환경에서만 사용 가능한데 예를 들어 프로덕션 조직으로 넘어오면 Apex를 사용해서 수정할 수 없다.
여러 환경에서 여러 사람들이 사용할 때 사소한 변경이라도 아래 사항들을 생각해 보아야한다.
예)예를 들어 연락처 표준 개체에는 연락처 유형에 대한 필드가 없을때 내가 해당 사용자 정의 필드를 추가하고 새 연락처 유형 필드를 모든 사용자에게 즉시 릴리스할 때
-
새 연락처 유형 필드가 다른 사람이 만든 사용자 정의와 충돌는가?
-
영업 팀이 새 필드를 사용하는 방법을 알고 있거나 교육이 필요한가?
-
필드가 필요한 경우 통합 또는 가져오기 프로세스를 업데이트해야 한가?
-
필드는 어디에 표시되나요? 모든 페이지 레이아웃에서? 어떤 목록 보기에서? 보고서 또는 대시보드에 표시되는가?
-
필드도 리드 개체에 있어야 하나요? 그렇다면 리드 전환 프로세스가 변경되는지?
-
다른 시스템과의 통합을 위해 필드가 필요한가? 그렇다면 미들웨어, 필드 매핑, 엔드포인트 등을 변경해야 할 수 있다.
1단계: 릴리스 계획
2단계: 개발
3단계: 테스트
4단계: 릴리스 빌드
5단계: 릴리스 테스트
6단계: 릴리스
단계로 진행한다. 자세히 내용들은 좀더 공부해야겠다.
