Hello Community,

 I would like to share my experiences over the last 6 months working on an implementation with 20+ devs, having Marketing Cloud, CPQ, Billing ( Around 20 Managed Packages) on using DX and Unlocked Packaging. I will focus mainly on how we were able to optimize for  build speed.

- Implement ScratchOrg Pooling ( Snapshot is not anywhere in sight, so we build a pool of Scratch Orgs ready for use in PRs and for developers. It takes around 5 hours to build 45 ScratchOrgs in parallel, a cron job replenish it throughout the day). This one really paid of, as our PR validation get to complete below 25 minutes.

-Check package coverage on the PR validation stage, Detect test classes from each package and trigger that and compute coverage, rather than waiting on packaging to report.

- Go granular with packages, at 6 month mark, we are working with 29 packages ( 22 Unlocked / 2 Org dependent/ 5 source packages). built mostly from a mono repo (we did isolate tech frameworks into its own repo).  For packages that are dependent on large managed packages, we decided to go to org dependent packaging/source packaging. Btw, Org dependent packages are super cool as they bring same functionality (yeah no validation, but its already done on the ScratchOrg)

-   Build packages that are only changed ( look at git diff and git tag) to identify which packages need to be built. This optimization  is essential when working in Mono Repo. This has led to a considerable savings of time, to bring back the average packaging stage run time under 25 mins.

- A full build of packages (not often required) when triggered is done under 45 mins., as packages are built parallel based on the dependency graph. Say B and C is dependent on A, but nothing else, as soon as A is created, trigger both B & C in parallel.

- Another thing, that we figured out was introducing a DEV sandbox into the build stage of the pipeline, so basically  after merge into mainline, we build all packages with skip validation and deploy to this sandbox. In parallel a dev can trigger the package validation stage if required. If the deployment is not good for any reason, the package validation stage is killed.  This means there is a higher confidence in the artifacts being produced and validated packages are reaching higher environments such as QA, Staging etc. (8 envs after Dev ;)

-Utilize the same approach during deployment, though our release is collection of all the packages going into a particular phase,  the release pipeline skips the installation of package if it finds the package is already installed in the org.

So far keeping the time build time monster under control, there are few more activities that are planned

- Still would prefer the mono repo, so may be do validation run's only certain change areas

- Optimizing our RBC deployments