Module: Application Lifecycle and Development Models -salesforce answers

I)Apex classes
II)Triggers
III)Workflow rules
IV)Reports and dashboards
[bg_collapse view=”button-orange” color=”#4a4949″ expand_text=”Show Answers” collapse_text=”Close Answer” ]
IV)Reports and dashboards
[/bg_collapse]

I)You know which ALM steps you can skip to save time.
II)The process helps you avoid breaking things, so the work proceeds more smoothly.
III)Time flies when you’re having fun.
IV)You don’t have to invest as much time into testing the release.
V)It takes the guesswork out of development by enforcing which tools you can use.
[bg_collapse view=”button-orange” color=”#4a4949″ expand_text=”Show Answers” collapse_text=”Close Answer” ]
II)The process helps you avoid breaking things, so the work proceeds more smoothly.
[/bg_collapse]

I)A build of all the metadata, changed and unchanged, that defines a specific app.
II)A step that commits changes to the target org just before deployment.
III)A build of metadata changes, possibly unrelated, to be deployed at the same time.
IV)A milestone past which you can no longer make changes to the build.
[bg_collapse view=”button-orange” color=”#4a4949″ expand_text=”Show Answers” collapse_text=”Close Answer” ]
III)A build of metadata changes, possibly unrelated, to be deployed at the same time.
[/bg_collapse]

I)Some metadata components might not yet be available in Metadata API, so they have to be migrated manually.
II)It ensures that the developers have met the design specifications.
III)It’s useful to keep track of which metadata components are used most frequently in releases.
IV)The team changing the most metadata components wins!
[bg_collapse view=”button-orange” color=”#4a4949″ expand_text=”Show Answers” collapse_text=”Close Answer” ]
I)Some metadata components might not yet be available in Metadata API, so they have to be migrated manually.
[/bg_collapse]

I)Developing programmatically ensures there are fewer changes to manage in the first place.
II)The team can do all of their development in a single org to avoid conflicting changes to apps.
III)Changes between team members can be merged in a controlled manner.
IV)They can use a scratch org as their version control system.
[bg_collapse view=”button-orange” color=”#4a4949″ expand_text=”Show Answers” collapse_text=”Close Answer” ]
III)Changes between team members can be merged in a controlled manner.
[/bg_collapse]

I)You can include destructive changes (such as deleting a field) in a release.
II)You can have release artifacts that contain changed and new metadata components.
III)You can use the Salesforce CLI to script routine tasks.
IV)You can select specific user data records to move to a different environment.
[bg_collapse view=”button-orange” color=”#4a4949″ expand_text=”Show Answers” collapse_text=”Close Answer” ]
II)You can have release artifacts that contain changed and new metadata components.
[/bg_collapse]

I)Changes to components not yet supported by source tracking.
II)Only the changes made via the Setup UI.
III)All metadata changes for the release.
IV)None. All the changes are tracked automatically.
[bg_collapse view=”button-orange” color=”#4a4949″ expand_text=”Show Answers” collapse_text=”Close Answer” ]
I)Changes to components not yet supported by source tracking.
[/bg_collapse]

I)It never expires.
II)You can share its definition file with others.
III)It’s an exact copy of your production org.
IV)Your source is automatically pushed to your VCS.
[bg_collapse view=”button-orange” color=”#4a4949″ expand_text=”Show Answers” collapse_text=”Close Answer” ]
II)You can share its definition file with others.
[/bg_collapse]