Decision Record for Sandbox Pooling

[CamSmith1]

Description

Checklist

All items have to be completed before a PR is merged

• [x] Adhere to Contribution Guidelines
• [ ] Updates to Decision Records considered?
• [ ] Updates to documentation at DX@Scale Guide considered?
• [ ] Tested changes?
• [ ] Unit Tests new and existing passing locally?

[azlam-abdulsalam]

Some thoughts

• Why don't we create this 'new' object on a sandbox?
• The ci job can then ask the username of the sandbox on where to store records.
• All developers need to be onboarded to this sandbox
• Fetch will fetch a record from the sandbox?

Thoughts @vuha-acn @CamSmith1

[CamSmith1]

Some comments:

• How about instead using the name "SandBoxInfo" use "DevSandboxInfo".
• Also, should we look to replicate most of the ScratchOrgInfo fields to mirror as much as possible on top of the additional fields we added as pre-reqs (eg. Allocation Status, Pool Tag).
• We should also track what release they are on for API.
• Authentication should we use AuthURL
• What about design for configuration file for project-ci-pool-def.json and dev pools as it relates to sandboxes that orchestrator will review.

Good suggestions,

1. Agreed that SandBoxInfoObject is a confusing name - For the time being it is a placeholder for a better name, SandBoxInfo is the tooling object and the intention is to create an sObject with an association to the tooling object so we can extend its capability e.g new fields. With that being said Im liking DevSandboxInfo over SandboxInfoObject

2. I have a diagram outlining the various fields, which didnt translate too well to .md format but we do have the intention to use Allocation Status and Pool Tag's as fields on the sObject

3)Agreed

4. We are currently exploring a few limitations that comes with AuthURL and sandboxes. For the time being and for MVP we have accepted the JWT workflow as our go to, But I think this can and should be explored as an option at a later state.

5. Good catch, I seem to have missed this section of the document completely. There are sections of this document that hint at a config file but I have not explicitly stated anything in that space. The expectation is that we can create a process as close to scratch org pooling as possible and this is something that we can and should implement.

[azlam-abdulsalam]

@CamSmith1 what's the current limitation with authURL?

It would be better if we make it uniform rather than introducing a new mechanism

[jhawk-4]

Hi @CamSmith1. Thank you for putting this together. I just want to have a brief convo about the idea of using the sandbox definition file. I realize that this may not be the ideal direction because of the decoupling from the DX CLI, but I do think the idea of having a definition file would be really helpful. One area that comes to mind is the ability to clone sandboxes as part of the prepare process. Having a definition file that defines a sandbox to clone from would be helpful in situations where you are creating pools of sandboxes for different purposes. For example, a developer sandbox pool may want to clone from a predefined dev sandbox. Each team could prep a sandbox to clone from differently and they could choose a different definition file that selects that sandbox during the prepare process. For a CI pool, you may want to clone from a different sandbox, or just create from production.

Some of my thought process here is that part of a CI pipeline might deploy a validated artifact to a team's predefined sandbox(es) that is (are) used in the cloning process. This could help speed up the prepare process as the creation will already have all previously validated artifacts in it. Having some sort of configuration file(s) within the repository could be helpful in providing flexibility during the prepare process much like it does for scratch orgs.

Even if the CLI is not used, it does seem like the name of the sandbox could be used in a query to the SandboxInfo object to get the ID which could then be passed to SourceId property on the SandboxInfo create request.

Apologies if this is getting too far into the weeds at this stage in the process, but wanted to get your take on the configurations that may be available for this process.

[vuha-acn]

@jhawk-4 - For the different type of sandbox clones, wouldn't those just be treated as one-off PoC Sandboxes once they get access to a pooled set of sandboxes? Based on the projects that I've been involved with, there hasn't been so many use cases for cloning customized dev sandboxes.

[jhawk-4]

@jhawk-4 - For the different type of sandbox clones, wouldn't those just be treated as one-off PoC Sandboxes once they get access to a pooled set of sandboxes? Based on the projects that I've been involved with, there hasn't been so many use cases for cloning customized dev sandboxes.

It really depends on the makeup of your org and teams. We have a few different teams at our company that are developing on managed packages that utilize custom objects for configuration. After all of that configuration data is loaded and any sample data you would want for development purposes, you are approaching the limits of a regular developer sandbox. If you are trying to have all of the teams utilize the same sandbox to clone from, then we are certainly past the data limits in this case. You would have a couple of options in this case. You could slim down the dev sandbox used for pooling and then have each developer be responsible for seeding the data per their needs. Or, you could have different templated sandboxes with different license types and different seed data that the pool could be created with. I.E., you could have a Dev Pro sandbox for a team that has higher limit needs and then a regular dev sandbox for all others. I guess my thinking was that it would just be nice to have the option to handle these scenarios through different configurations to suite the needs of different teams.

[azlam-abdulsalam]

This DR will be closed and is decided not to be featured in sfpowerscripts, but as a separate utility. Stay tuned, Thanks everyone