Development Lifecycle and Deployment Designer

Development Lifecycle and Deployment Designer

ABOUT THE EXAM

For specialists who implement management solutions on the Salesforce Platform that meet development and deployment requirements.Get the Exam Guide

Study & PrepareLearn at your own pace with a learning path designed just for you.

Architect Journey: Development Lifecycle and Deployment

Grow your architect skills and expertise in the area of Development Lifecycle and Deployment. This Trailmix has been curated just for you!

EXAM OUTLINE

The Salesforce Certified Development Lifecycle and Deployment Designer exam measures a candidate’s knowledge and skills related to the following objectives. 

ENVIRONMENTS 15%

• Given a customer landscape and their requirements, evaluate business, technical, and architectural considerations while defining an appropriate org strategy.
• Given a customer scenario, define an environment (sandbox) strategy that utilizes the correct sandbox types (e.g., multiple project streams, training requirements, staging, production, and hotfixes).
• Apply map sandbox strategy to a specific Release Plan, taking into consideration multiple project streams, training requirements, staging, and hotfixes.
• Given a customer scenario involving a new Salesforce release, recommend the appropriate strategy to mitigate risk.
• Given a detailed customer environment scenario including a specific request, explain the implications for incorporating the request directly in a production environment.
• Given a customer scenario, explain how source control branching/versioning/merging can be used and recommend appropriate strategies.

APPLICATION LIFECYCLE MANAGEMENT 17%

• Given the project risk and customer requirement, explain how to assess the benefits and risks of the different development methodologies and recommend the appropriate methodology based on the customer environment.
• Given a customer scenario, describe and recommend an appropriate release management strategy.

TESTING 10%

• Given a customer scenario, describe and recommend an appropriate testing methodology.

GOVERNANCE 17%

• Given a customer scenario, analyze and recommend the appropriate governance framework.

RISK IDENTIFICATION AND MITIGATION 12%

• Understand customer environment risks and articulate appropriate mitigation strategies.

CHANGE SETS 5%

• Given a scenario, compare, contrast and recommend the components and tools of a successful deployment strategy.

METADATA API 10%

• Given a scenario, describe the capabilities, limitations, and considerations when using the Metadata API for deployment.

CONTINUOUS INTEGRATION TECHNIQUES 8%

• Given a complex customer scenario ability, identify the appropriate use of source control, automated test, and deployment tools and demonstrate the ability to articulate the process involved. 

METHODOLOGY TOOLS 3%

• Explain the advantages of using agile tools to support an agile development process.

UNDERSTANDING PACKAGES 3%

• Given a scenario, analyze and explain the use cases and considerations when using managed vs. unmanaged packages. 

Topic

Force.com Migration tool(Ant)와 Change set의 차이점

Ant툴의 경우 Change set과는 다르게 연결되어 있지 않은 오그에도 metadata를 migration 할 수 있음
ant툴은 gui가 없는 cmd방식임 deploy(retrieve)할 components를 xml을 수정하여 관리
change set은 web tool에서 components를 선택하여 deploy할 수 있음

Production에서의 일반적 개발 lifecycle

기능 요건 정의
Web tool에서 개발(배포전까지 프로필에서 해당 기능을 hide)
개발된 기능을 유저의 프로필에 권한 설정
유저에게 공지

Sandbox에서의 일반적 개발 Lifecycle

개발환경 구축
Web/local Tool로 개발
개발환경에서 테스트
프로덕션의 변경사항을 개발환경에 반영 재 테스트
개발내용 프로덕션 배포

SFDC에서 말하는 개발(프로젝트)이란?

새로운 Custom Object 생성, 탭 생성, 어플리케이션 생성, 타 시스템과 연동
Apex사용 앱, Visualforce, workflow, 신규 validation rules, 등
Environments에 수정/변경을 하는 모든 사항을 개발이라함

Sandbox의 목적

개발, 테스트, 교육, 프로덕션의 데이터/기능의 영향을 주지 않는 다른 목적들

연결된(Related) 오그간 Metadata를 Migration하는 가장 쉬운 방법

Change set

통합, 테스트 및 스테이징이 있는 다수의 프로젝트가 동시의 진행되는 개발 Lifecycle

• 개발환경 설정
• 각각의 개발환경에서 web/local 툴로 개발
• UAT, Test, Integration 환경을 구축
• 버전관리된 개발 metadata를 통합 환경으로 마이그레이션
• 테스트.
• metadata를 UAT 환경으로 마이그레이션
• UAT 
• UAT환경의 Metadata를 스테이징 환경으로 마이그레이션
• 프로덕션의 변경사항을 스테이징에 반영 / 테스트
• 배포

Sandbox 종류

Developer sandboxes 개발, 프로덕션 데이터 복제 불가
Developer Pro sandboxes 개발, 프로덕션 데이터 복제 불가, 추가 스토리지
A Partial Copy sandbox 디벨로퍼 샌드박스 + Template를 이용한 프로덕션 데이터 일부 복제 가능
Full sandboxes 모든 레코드 Documents, 첨부파일까지 복제 가능
29일 단위로 갱신 가능

외부연동 테스트에 가장 적합한 sandbox

full sand box
연동에 데이터 의존성이 있을수 있고 실제 환경과 동일하게 테스트 해야
잠재적 오류를 발견할 가능성이 높다
다만 부분적인 연동 테스트의 경우 partial sandbox를 사용 할 수도 있다.

개발에 가장 적합한 sandbox

Developer, Developer pro
당연한 얘기지만 일정에 쫒겨 Partial에서 직접 개발해서
I/F테스트와 개발이 동시에 돌아가서 변화관리에 애먹어본 경험이 있어
다시 한번 가슴에 새깁니다 ㅠ.ㅠ

UAT, Staging에 가장 적합한 sandbox

Full sandbox
Staging에서 이미 Full의 냄새가.....
UAT의 경우 Partial에서 지역, 부서별 테스트를 진행 할 수도 있음

debugging에 가장 적합한 sandbox

Full sandbox
release이후 debugging, Hot Fix를 위해 Full sandbox를 이용
(I/F Test에도 쓰고 UAT에도 쓰고, Staging에도 쓰고, Hotfix에도 쓰면 돈이....)

Unit test, Apex Test 가장 적합한 sandbox

developer, developer pro sand box........

Feature 또는 Regression tests에 가장 적합한 sandbox

Partial sandbox(기본 데이터(만/를) 로드한 상태)

sandbox에서 비활성화 되어 있고 활성화 할수 없는 feature

https://help.salesforce.com/articleView?id=data_sandbox_implementation_tips.htm&type=5
Service Exclusions 섹션 확인

• Contract expiration warnings
• Case escalation

위 2 기능은 Contact, Customer, User에게 자동으로 메일을 발송하기 때문에 비활성화

• Subscription summary

컨텐츠등 구독 항목의 서머리 메일이 발송되지 않는다.
(Chatter Summary는 설정에 따라 발송된다)

• Data exports (by clicking Export Now or Schedule Export on the Weekly Export Service page in Setup)
• The ability to create Salesforce sandboxes

샌드박스에서 샌드박스는 만들 수 없음

• The ability to copy email service addresses that you create in your sandbox to your production org

샌드박스에서 만든 이메일 서비스를 프로덕션으로복사 불가

• The ability to publish Site.com sites

안써봐서 모르겠지만 안된다고 함

environmental dependencies

Production, Sandbox 환경에 종속적인 요소
예를들면

• 로그인 권한
• 이메일 주소설정
• 이메일 수신자 설정
• 외부 URL
• 하드코딩된 URL
• 하드코딩된 ID값
• Existing Projects

Sandbox는 Production과 동일한 License를 가진다.

sandbox 생성 후 프로덕션의 license 변동이 있을경우 sandbox에서
Company Profile | Company Information | Match Production Licenses.
를 통해 라이센스를 갱신 할 수 있다.

User Template

샌드박스를 생성/갱신할때마다 개발자(테스트 등) 유저를 매번 생성하는 일을 방지하기 위해 프로덕션에 생성해둔 유저(inactive)
구성 방법은

• 프로덕션에 목적에 맞는 권한을 부여한 유저를 생성한다.
• 해당 유저는 Inactive시켜둔다.
• sandbox를 생성/갱신한다.
• 해당 유저를 활성화 한다.
• email, password, 그외 설정등을 필요할 경우 수행한다.

샌드박스 활성화 시 고려사항

• 샌드박스 생성은 데이터의 양(Full sandbox), 설정내역, 커스터마이즈 범위, 오브젝트수, 서버 상태에 따라 몇분에서 몇주까지 걸릴수 있다. 생성 요청 즉시 생성 작업이 진행되는 것은 아니며 큐에 들어간다. 그래서 생성시 데이터 양을 최소화 해야한다.
• 샌드박스 갱신은 삭제 후 프로덕션일 복재 재 생성한다. 기존 샌드박스에서 했던 작업은 프로덕션에 반영되지 않았다면 전부 유실된다. 만약 샌드박스에서 개발등의 목적으로 유저를 생성한 경우 전부 삭제된다. 그 경우 재 생성을 방지하기 위해 프로덕션에 User Template를 생성해 두어야 한다.
• 샌드박스 생성/갱신 중 설정작업 또는 데이터 변경이 발생할 경우 정합성 불일치가 발생 할 수 있다. 따라서 샌드박스 생성 중에는 프로덕션의 모든 변경을 멈추거나 최소화 해야 한다.

Admin이 사용하기 제일 쉬운 개발 환경

Web tool(force.com setup)

Force.com IDE

대부분의 metadata(Metadata API가 지원하면서 Force.com IDE update따라)를 개발할수 있는 개발환경
이클립스에 plug-in으로 사용하며 wizards, source code editors, test execution tools,
deployment aids(Deploy to Server), integrated help, interactive debugger를 포함하고 있다.

Sandbox Management Best Practices

Sandbox Management Best Practices.pdf 

Force.com IDE를 사용하여 Project-base로 개발시 잇점

세일즈포스 오그의 여러 컴포넌트들을 텍스트 기반의 파일로 관리 할 수 있다.
파일로 관리하면 이관이 쉽고 버젼관리 툴로 저장, 관리하기 쉽다.
이러한 장점은 Metadata API로 인해 가능하다.

Force.com IDE의 제약

한번에 최대 10000개/39MB(zip file) 배포, 조회가능
그 이상은 분할하여 처리해야함

Force.com IDE에서 프로젝트를 구성시 고려사항

당장의 구현 목표를 기준으로 프로젝트 구성요소를 설정한다.
추후 필요에 따라 구성요소를 추가하거나 제거할 수 있다.

MetaData API 활용법

setup configuration을 파일로 작성/관리한다. 메타데이터를 익숙한 툴로(텍스트 에디터, IDE, 스크립트, 버전컨트롤)
복사, 붙여넣기, 병합, 생성 한다.
연결과 관계없이 오그의 설정값을 메타데이터로 마이그레이션 한다.
직접 메타데이터 API를 통해 오그, 어플을 관리하는 툴을 만들 수 있다.

Force.com Migration Tool

metadata를 로컬파일에서 오그로 이동시키는 Java/Ant 기반의 command-line 도구
동일 작업을 반복하는데 용이, 대량의 설정이동에 적합, 스크립트를 이용해 다단계 배포 프로세스에 적용하기 용이

변경사항을 꼭 기록해야되는 이유!

Metadata API, Change Set이 지원 안해서 손으로 변경사항을 반영해야하는 구성요소가 있기때문에!!
그리고 덮어쓰는것을 방지하거나 복구하기 위해 누가 어디서(오그) 어떤요소를 언제 변경(배포)했는지 기록해야함

What is a Change Process?

Change Process는 프로덕션에서 발생할 수있는 수정의 종류, 발생할 수있는시기 및 변경 책임자를 결정합니다.

Best practices for Change Processes

• 프로덕션에서 변경을 금지함
• 컴포넌트는 Metadata API로만 반영
• 한명의 어드민이 변경반영
• 프로덕션 배포를 일정계획에 따라 진행

Data Loader Guide

개발프로젝트를 계획할때 사용하는 개발 진행의 위치를 판단하는 범주 4가지

• Production Only

프로덕션의 웹 인터페이스에 전체 구현/테스트가 가능한 경우 빠른 개발이 가능하며 그로 인해 사용자는 더 빨리 기능을 사용할 수 있음

• Metadata API Components

모든 컴포넌트가 Metadata API에서 지원하면 환경간 변경사항을 추척하고 병합하기 용이함

• Single Sandbox

샌드박스에서 개발 후 즉시 프로덕션의 적용 할수 있을 경우
통합 환경이나 스테이징 환경은 필요하지 않음

• Multiple Environments

개발 프로젝트가 여러 샌드박스에 걸쳐있으며(여러개발자) 복잡성이 높을 경우
코드 병합이 어려워짐. 복잡한 개발상황이라도 간단한 기능 적용이 누락되면 안됨

개발프로젝트를 계획할 때 사용하는 개발자의 수에따라 판단하는 범주

•  1인 개발

개발자 1인이 기능의 개발 테스트 배포를 커버 할 수 있는 경우 변경을 병합하는 도중 발생하는 문제나 다른 시간을 잡아먹는 이슈가 발생할 가능성이 적어짐

• Small team

소규모 팀은 대형 프로젝트를 관리 가능한 크기로 분할 할 수 있으며 신속한 개발이 가능합니다.
단일 개발자 프로젝트와 쉽게 통합되고 신속하게 배포 될 수 있음

• Large team

대규모 개발 프로젝트에는 온전한 개발 팀이 필요 이런 프로젝트는 개발 과정을 느리게 할 수있는 다른 코드 브랜치
테스트 및 기타 관련 프로세스의 변경 사항을 추적하고 병합해야함

Release Train

정기적으로 어플리케이션의 업그레이드를 제공하는 스케쥴링 기술
릴리스 트레인은 예측 가능하고 점진적임
개발사이클의 제한을 설정하여 개발 프로세스를 간소화함

What is the general process for delivering multiple applications on a release train?

여러 어프리케이션을 릴리즈트레인을 통해 제공하는 일반적 프로세스

• 세일즈포스 업그레이드 시점 주변에 릴리즈를 계획함
• 동시진행하는 프로젝트를 일정을 조정함- 릴리즈 시점에 개발을 완료하여 배포할 것인지 다음에 배포할것인지
• 프로덕션 변경 계획 수립@_@?
• 모든 환경에서의 변경내역을 추적 - 간단한 기능이 덮어씌이지 않도록
• 변경내역을 통합 후 스테이징 또는 테스트 환경에 배포
• 프로덕션에 배포

세일즈포스 릴리즈 업데이트시 변경되는 몇가지

• New logo

로고가 바뀌어서 릴리즈가 업데이트 된걸 빠르게 확인가능

• New features

새로운 기능이 추가되고 새로운 컴포넌트가 Metadata API를 통해 사용가능

• Incremented API version

API 버전이 올라가고 새로운 기능은 새 버젼의 API통해 접근 가능

• Staggered upgrades

샌드박스와 프로덕션은 동시에 업그레이드 되지 않음 선행 업그레이드 된 샌드박스에서 개발한 내용은
신규 기능을 사용한 경우 프로덕션이 업그레이드 될때까지 배포 할 수 없고 신규 기능과 상관없는 기능은
API 버젼을 프로덕션 버전과 일치시켜 배포 할 수 있음

Salesforce Context에서 Migration의 의미

오그에서 다른 오그로 Configuration변경 사항을 이동시키는 행위

Migration 방법

• Manual

Metadata API가 제공하지 않는 구성요소는 수동으로 마이그레이션 해야함
모든 환경에서 동일 작업 필요

• Metadata

Change set 또는 Metadata API에서 제공하는 구성요소의 경우
Local tools(Force.com IDE, Migration Tool)를 사용하여 마이그레이션

마이그레이션 절차

1. 우선 마이그레이션 할 컴포넌트 선정
  만약 수기 작업과 메타데이터 마이그레이션을 같이 해야할 경우 매우 중요
  예를 들어 커스텀 오브젝트에 큐를 생성할 경우 커스텀 오브젝트 먼저 마이그레이션 해야함
2. 필요한 순서에 따라 구성 요소 마이그레이션
  변경 목록을보고 수동으로 마이그레이션해야 할 것이 있는지 판단
  변경 사항을 마이그레이션하고 수동으로 변경
  최신 메타 데이터 변경 사항을 확인
3. 필요에따라 Force.com 프로젝트 또는 아웃 바운드 Change set을 수정하여
  구성 요소의 하위 집합 만 배포
4. 배포

프로덕션을 변경하고 샌드박스를 새로 고침하지 않은 이유

• 풀 샌드박스의 경우 이전 갱신이 29일 이내면 불가
• 구성 요소 종속성이 배포에 중요한 역할을하는 경우 프로덕션에서 변경하면 샌드 박스에서 개발 한 응용 프로그램을 배포하지 못할 수 있음
• 프로덕션의 모든 변경 사항은 각 개발 조직에서 수동으로 마이그레이션해야함
• 개발오그가 여러개인 경우 프로덕션에서 샌드박스로 변경 사항을 여러 번 수동으로 마이그레이션해야함

배포 작업 시간에 영향을 주는 요인

• Number and size of files

배포작업이 많을수록 배포 시간이 오래 걸림
네트워크 페이로드는 거의 10MB보다 크지 않으므로 파일 크기는 큰 영향없음

• Type of components

일부 구성 요소는 다른 구성 요소보다 처리하는 데 시간이 오래 걸림
사용자 정의 필드, 사용자 정의 junction 오브젝트 및 프로파일은 다른 구성 요소보다 오래 걸림

• Processing time

데이터를 다시 계산해야하는 변경 작업을 수행하려면 수정해야하는 데이터 양에 비례 한 시간이 걸림
필드 유형을 변경하려면 해당 필드를 사용하는 모든 레코드를 수정해야 함

• Test execution

Apex 테스트의 수와 복잡성은 배포 시간에 큰 영향 줌

• Network and server availability

이들은 다른 요인들에 비해 영향이 적음
그러나 근무시간이 아닐때 배포작업을 진행하면 락에 의한 대기없이 바로 배포가 진행됨

• Locking

사용중인 구성요소를 배포할때 락이 풀릴떄까지 대기

Deployment Status page list

Change set 배포, Force.com IDE 및 Force.com Migration Tool에서 시작한 Metadata API 기반 배포, 패키지 설치가 표시됨

Quick Deploy

Validation을 통과한 배포를 4인 이내에 Re-validation없이 배포가능
local/all test의 경우 평균 75% 이면서 트리거는 조금의 커버리지가 있어야 specific test의경우 각각 75%

샌드박스에서는 부분배포 가능

deployment options에서 rollbackOnError 를 false로 설정하면 가능 failed 컴포넌트는 커밋하지 않고 나머지는 커밋함

Metadata API 또는 the Force.com Migration Tool에서 Quick deploy하는법

• For Metadata API - call deployRecentValidation() and pass it the validation ID.
• Force.com Migration Tool - use the <sf:deployRecentValidation> task.

Apex Test가 오래걸리는 이유

@isTest(SeeAllData=true)를 써서 오그에 데이터가 많으면 느려짐 또는 코드가 엉망

Deployment Dependencies

• Parent-child—Metadata components may depend on other components.
• Referenced file—Every file that is referenced by another file must either be included in the deployment plan, or already in the destination organization.
• Ordering—Dependencies require that components are deployed in a specific order, and within a single deploy operation, this order is handled automatically by the Metadata API. However, if you deploy a subset of components, or split your deployment into multiple batches, you must take into account the ordering dependencies yourself.
• Mandatory fields—When you create an object using the Force.com IDE or the Salesforce user interface, the tool enforces the creation of mandatory fields.

배포를 분할해야되는 이유

• The deployment is too large

You can deploy or retrieve up to 10,000 files at once and the maximum size of the deployed or retrieved .zip file is 39 MB.

• Long deployments

If you experience unusually long deployments, you can divide your deployment into smaller pieces. Smaller deployments can reduce user impact due to locks being held in long-running operations.

• Apex testing

You might want to divide your components into two parts: those that require testing by default and those that don't. Testing only those components that require testing speeds deployment and locks fewer components.

분할 기준

• 테스트가 필요한 것과 필요없는것
• 종속성이 있는것들끼리
• 수가 많은것 부터
• 이메일 템플릿은 분할해도 되지만 구성요소가 먼저 배포되어 있어야함
• 대쉬보드는 분할해도되지만 구성 리포트가 먼저 배포되어 있어야함
• 레포트는 많은 구성요소를 포함하고 있기때문에 다른 구성요소가 먼저 배포 된 후에 배포해야함

Package를 사용하여 migration하는것이 비효율적인 이유

Unmanaged Package는 동일 구성요소를 배포할 수 없다.
다만 초기 설정을 설치하는 용으로 사용할 수 있다.
Managed Package는 IT 개발 도구로 사용하기에 적합하지 않은 제약 조건을 추가함

Migration Best practices

• 사용자가 조직을 변경하지 않는 기간 동안 배포하는 것이 중요
• 배포의 성공을 보장하기 위해 테스트 배포를 수행해야함
• 배포는 전체 아니면 제로 이벤트
• 프로덕션에 배포하기전 사전고지 기간 중 테스트 배치를 수행 할 수있는 스테이징 환경을 생성하거나 새로 고침
• 스테이징 환경에 테스트 배포를 진행할때 웹인터페이스에서 진행된 수기 마이그레이션을 전부 완료해야함
• 스테이징에서 테스트 배포시 수동으로 All test를 실행하여 이슈 확인

엔터프라이즈 규모의 마이그레이션 실행 시 절차

• Announce a maintenance window.
• Stop all setup changes on production.
• Create a staging environment.
• Migrate changes to the staging environment.
• Change environmental dependencies and services from testing settings to production values.
• Lock users out of the application.
• Test deploy using the Metadata API.
• Deploy to production.
• Unlock the production organization.

신규 기능을 배포할때 준수사항

1). 어느것도 오작동하지 않게 해야함
a. 풀센드박스에 프로덕션과 동일하게 환경 설정 후 신규 기능을 배포, 전체 기능을 테스트 한다. 이상 없을 시 프로덕션에 배포한다
b. 모든것을 백업해둔다.
c. 실패시 복구 플랜을 세운다
2). 릴리즈의 일정을 수립한다.
a. 유지보수 알림창을 설정하고 사용자의 접근을 제한한다.
b. 사용자 프로필을 조정하여 접근을 제어한다.
3). 모든 사용자에게 공지한다.
a. 신규 개발된 기능 환경에대한 릴리즈 노트를 작성하여 사용자에게 공지한다.
b. 메인 기능에대한 안내 메일, 릴리즈 노트로의 링크를 포함한 안내메일을 발송한다.
c. 웨비나 또는 교육세션을 통해 사용자를 교육한다.

배포 동안 프로필을 조작하여 메인터넌스 윈도우를 관리하는 방법

배포 동안 대부분의 사용자를 잠그는 사용자 프로필의 로그인 시간 편집. 필요하다면 시스템 관리자 나 통합 사용자가 액세스 할 수 있는지 확인

조직에 프로필이 많고 유지 관리 기간 동안 사용자를 잠그고 싶다면 어떻게해야합니까?

• 모든시간 로그인 할수 없도록 설정된 프로필 생성
• 데이터 로더로 프로필정보를 포함한 유저의 전체 레코드를 다운로드
• 메인터넌스 윈도우가 시작되면 1에서 생성한 프로필을 적용하여 데이터로더를 통해 . 어드민을 제외한 유저 레코드를 업로드 로그인을 못하게 한다
• 메인터넌스 윈도우가 종료되면 원래의 유저 레코드로 복구한다.

버그잡이 best practice

• 모든 변경사항을 한곳으로 모은 후 그것을 반복 가능한 프로세스로 프로덕션으로  배포한다.

(분할배포하여 버그를 찾은 후 그 부분만 다시 배포하려고? 말이 너무 애매함-_-)

• 만약 프로덕션에서 변경작업을 진행했다면 그 내용을 개발환경에도 반영해 두어야 다음 배포때 이전 버그가 재발하지 않는다.

(프로덕션에서 확인 수정이 가능한경우는 아마 포뮬라나 프론트쪽일꺼고 까먹지말고 개발서버에도 반영해 두라는 얘기겠지....자주 개발에 반영안한사람 반성합니다.)