#Ci/cd0 personne en discute

Developer Spotlight: Meet Nicolas Vuillamy

Our latest developer spotlight is on @Nicolas Vuillamy, the creator of an open-source sfdx plugin with a Visual Studio Code Extension — sfdx-hardis — that simplifies many Salesforce workflows, especially around DevOps and CI/CD.

Meet him here: https://developer.salesforce.com/blogs/2024/01/nicolas-vuillamy-builds-a-career-path-to-cto-in-the-salesforce-ecosystem

#SFDX #Sfdx Plugins #Ci/cd #Devops

Resources from the Salesforce Developers Ask Me Anything on Salesforce CLI

I hope you joined us for the fantastic #SFDevsAMA on Wednesday 14th December featuring @Peter Chittum, @Pooja Reddivari and @Peter Hale. They loved answering your questions about the CLI. If you missed it, don't worry - we recorded the session and our experts have provided some great resources that our experts for you to continue your learning! 

Still have questions? Post them in this thread for our experts!

• Watch the recording on demand
• Developer Quick Take: Exploring the sf CLI
• Contribute to the Salesforce CLI
• Overview Videos
  • Exploring the sf CLI
  • Building a CLI Application with oclif
  • How to Build a Salesforce CLI Plug-In?
  • codeLive: How to Write NUTS Test Cases for Salesforce CLI Plug-In
• Building a CLI Application with oclif
• Documentation
  • Salesforce CLI Setup Guide
  • Salesforce CLI Reference Guide
  • sf Plugin Developer Guide
  • Salesforce DX Developer Guide
  • VSCode Guide
  • Salesforce Code Builder
• Release Notes
  • Salesforce CLI Release Notes (sfdx Commands)
  • Salesforce CLI Release Notes (sf Commands)
• Learn more about DevOps Center GA
• Log an Issue with CLI through GitHub - CLI engineers handle these issues directly

#Ask An Expert #SFDX CLI #CICD #Ci/cd #Devops #DevOps Center

Starting in 4 Hours: Ask Me Anything about Salesforce CLI

14 Dec 2022: Our Salesforce experts today are @Peter Chittum, @Pooja Reddivari and @Peter Hale. They'll be answering all your questions about Salesforce CLI.

To participate:

1. Ask your question here ⬇️ using the SFDevsAMA tag.
2. Join us for the broadcast here to see your question answered!

See you soon!

#SFDX CLI #CICD #Ci/cd #Devops

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

Fala Pessoal, espero que estejam todos bem e em suas casas!

Estou passando aqui para relembrá-los que teremos na quinta uma sessão IMPERDÍVEL do @Tiago Nascimento  sobre Release Management com uma demo Hands-on show de bola.

Como teremos muito conteúdo, tivemos que adiantar a sessão em 30 minutos. Começaremos às 18:00 dessa vez.

**** IMPORTANTE ****

Atendendo a pedidos, aproveito também para deixar aqui a nossa playlist dos encontros virtuais anteriores no Youtube, para quem não conseguiu acompanhar todos eles. Salvem em seus bookmarks!.

https://www.youtube.com/playlist?list=PLWCkHg0zFNMfirjsUohpo47wj1-dDzIPj

Esperamos vocês!

@Leandro Esteves Barion  @T. Marinho 

@Arquitetos Salesforce de Clientes Brasil  @* Success - Português * 

#EncontroDeArquitetos  #Release Management  #Ci/cd