Salesforce Exam Development Lifecycle and Deployment Architect Topic 9 Question 33 Discussion

Actual exam question for Salesforce's Development Lifecycle and Deployment Architect exam

Question #: 33
Topic #: 9

[All Development Lifecycle and Deployment Architect Questions]

Universal Containers (UC) has a customized repository that represents lots of different

apps or projects. UC currently is trying to shift from the org development model to the package

development model to manage changes. In the org development model, each developer starts

their work within their own personal sandbox.

When it comes to choosing development environments, what should a Salesforce architect

recommend?

AStart using scratch orgs because a developer can spin up a scratch org to start a new
project, start a new feature branch, or start automatedTesting.

BStart using scratch orgs that tracks all of the changes automatically and proceed with a
staggered approach since scratch orgs can coexist With other models.

CKeep developing in the dev sandboxes because scratch orgs are not within the code
deployment path.

DKeep developing in the dev sandboxes, so that the developers feel no impact at all as they
are used to the sandbox development.

Show Suggested Answer

Suggested Answer: A

by Daren at Apr 10, 2024, 03:58 AM

Limited Time Offer

25%

Off

Get Premium Development Lifecycle and Deployment Architect Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

Submit Cancel

Lavera

6 months ago

I'm with Lynda and 2 on this one. Scratch orgs are the way to go. They're like the superheroes of the development world, swooping in to save the day with their automatic change tracking and coexistence with other models.

upvoted 0 times

...

Noel

6 months ago

Haha, Aleisha must be stuck in the past. Scratch orgs are the way of the future, and they're way cooler than those old-school sandboxes. Time to embrace the change, my friend!

upvoted 0 times

Maynard

5 months ago

B) Start using scratch orgs that tracks all of the changes automatically and proceed with a staggered approach since scratch orgs can coexist With other models.

upvoted 0 times

...

Brandee

5 months ago

A) Start using scratch orgs because a developer can spin up a scratch org to start a new project, start a new feature branch, or start automatedTesting.

upvoted 0 times

...

Aleisha

6 months ago

But what about the dev sandboxes? They've been around forever, and developers are comfortable with them. Why fix what isn't broken?

upvoted 0 times

Dean

5 months ago

C) Keep developing in the dev sandboxes because scratch orgs are not within the code deployment path.

upvoted 0 times

...

Dallas

5 months ago

B) Start using scratch orgs that tracks all of the changes automatically and proceed with a staggered approach since scratch orgs can coexist With other models.

upvoted 0 times

...

Dyan

5 months ago

A) Start using scratch orgs because a developer can spin up a scratch org to start a new project, start a new feature branch, or start automatedTesting.

upvoted 0 times

...

Minna

6 months ago

I see the benefits of option B, but I still lean towards option A for its simplicity.

upvoted 0 times

...

Stephaine

6 months ago

I prefer option B as well, having the ability to coexist with other models is important.

upvoted 0 times

...

Twanna

6 months ago

But what about option B, where we can track changes automatically?

upvoted 0 times

...

Christa

7 months ago

I agree, using scratch orgs for starting new projects makes sense.

upvoted 0 times

...

Leota

7 months ago

I agree with Lynda. Scratch orgs are the future, and they make the development process so much smoother. Definitely the recommended choice here.

upvoted 0 times

Wilda

5 months ago

B) Start using scratch orgs that tracks all of the changes automatically and proceed with a staggered approach since scratch orgs can coexist With other models.

upvoted 0 times

...

Shawnna

6 months ago

A) Start using scratch orgs because a developer can spin up a scratch org to start a new project, start a new feature branch, or start automatedTesting.

upvoted 0 times

...

Barbra

6 months ago

B) Start using scratch orgs that tracks all of the changes automatically and proceed with a staggered approach since scratch orgs can coexist With other models.

upvoted 0 times

...

Bernardine

6 months ago

B) Start using scratch orgs that tracks all of the changes automatically and proceed with a staggered approach since scratch orgs can coexist With other models.

upvoted 0 times

...

Evangelina

6 months ago

A) Start using scratch orgs because a developer can spin up a scratch org to start a new project, start a new feature branch, or start automatedTesting.

upvoted 0 times

...

Catina

6 months ago

A) Start using scratch orgs because a developer can spin up a scratch org to start a new project, start a new feature branch, or start automatedTesting.

upvoted 0 times

...

Lynda

7 months ago

Option A is the way to go! Scratch orgs are a game-changer for managing changes. You can spin them up in a flash and start your new project without any hassle.

upvoted 0 times

Brinda

6 months ago

A) Developers should definitely consider making the switch to scratch orgs for a more efficient workflow.

upvoted 0 times

...

Vincent

6 months ago

B) Absolutely, it streamlines the development process and ensures better code quality.

upvoted 0 times

...

Merilyn

6 months ago

A) Plus, the automated testing feature in scratch orgs is a huge benefit for developers.

upvoted 0 times

...

Heidy

6 months ago

B) I agree, scratch orgs make it so much easier to start new projects and features.

upvoted 0 times

...

Mitsue

6 months ago

A) Option A is definitely the way to go! Scratch orgs are a game-changer for managing changes.

upvoted 0 times

...

Yolande

7 months ago

B) Start using scratch orgs that tracks all of the changes automatically and proceed with a staggered approach since scratch orgs can coexist With other models.

upvoted 0 times

...

Cristy

7 months ago

A) Start using scratch orgs because a developer can spin up a scratch org to start a new project, start a new feature branch, or start automatedTesting.

upvoted 0 times

...

Minna

7 months ago

I think option A is the best choice.

upvoted 0 times

...

Edna

8 months ago

I don't know, you guys. Keeping the dev sandboxes feels like the safe choice to me. Why fix what ain't broken, you know?

upvoted 0 times

...

Bernardo

8 months ago

You know, I heard that scratch orgs automatically track all the changes. That sounds like a real time-saver! Plus, I'm always losing track of my local branches, so that feature would be a lifesaver.

upvoted 0 times

...

Truman

8 months ago

Personally, I'm leaning towards the staggered approach with scratch orgs. That way, we can test the waters and ensure a smooth transition, without totally disrupting our current workflow.

upvoted 0 times

...

Raina

8 months ago

Ha! Forget about the sandboxes, I say we just live in the scratch orgs full-time. Who needs sunlight and human interaction anyway?

upvoted 0 times

...

Roxane

8 months ago

Scratch orgs seem like a good solution, but I'm not sure about the impact on the deployment process. I don't want to throw off the whole system, you know?

upvoted 0 times

Harrison

6 months ago

B) Start using scratch orgs that tracks all of the changes automatically and proceed with a staggered approach since scratch orgs can coexist With other models.

upvoted 0 times

...

Rima

7 months ago

A) Start using scratch orgs because a developer can spin up a scratch org to start a new project, start a new feature branch, or start automatedTesting.

upvoted 0 times

...

Winfred

8 months ago

This question is a tricky one! The org development model is so ingrained in our processes, it's hard to imagine shifting to the package development model. But I guess that's the challenge we need to tackle here.

upvoted 0 times

...