1. Thursday, 21th September , 2023
Salesforce Luxembourg
User Group

2. CI/CD and Dev-ops in
a SF environment

3. Who has
implemented
?
Who would
like to ?

4. Applications became more business critical
From sales funnel to operational processes,
or operational processes integration
Application are more and more subject to
compliance and security rules
GDPR, PSF, Healthcare, …
-> auditability : changelog (code, profiles,
…), but security vulnerability
Different actors involved
CRM team
CRM consultants from different companies
SF Premier Support
-> who is doing what ?
Application became more complex
From « classic » some years ago, with some
rules, and apex code and VF
To « lightning », with LWC, flows, more Apex, …
Bigger teams and work collaboration
From mono-application to multi-application
One Owner -> Multi Owner
App Exchange and related customization
Side effects
More and more integrations
Leads to more ‘fragility’ and ‘dependencies
Salesforce organization evolved
Context Implementations

5. Different SF lifecycles appears over the last 20 years
Metadata flows
• Production<->Sandbox via change sets
• Repositories -> Scratch Orgs -> Sandboxes -> … -> Production
• Change Sets / Packages / Deploy from Repositories /…
Development Tools
• SF GUI (Direct Edit + Console)
• Visual Studio, IntelliJ, …
• SFDX and CLI
Generic CI/CD tools
• Repositories : git
• And CI/CD tools (Jenkins, GitLab, BitBucket)

6. How to deal with this evolving situation
in your Dev and Ops Teams
As usual
• With associated risk and workloads
Complex CI-CD setup
• Repository
• Pipe Jenkins, etc
• -> Big organization to set up and maintain the stack
Configurable off-the-shelf solution
• GearSet
• Copado
• AutoRabit

7. One under the microscope : Gearset
Metadata
Backup
Data
Monitoring

8. DevOps for Salesforce
—
What are the main constituents of Salesforce DevOps?
8

9. 9
Traditional SFDC
dev/ops
—
1.Devs own everything in
orange - making their own
changes in their sandboxes
2.Ops people own everything
in turquoise - packaging
changes, deploying them, and
maintaining production
3.Deployments are org-to-org
4.This is normally done using
change sets, or entirely manually
in the case of types like profiles
5.This packaging and release
process is often cumbersome
and iterative - if a deployment
fails, tweak the package, and try
again

10. 10
SFDC DevOps
—
1.Devs still own making
changes in their own sandboxes
2.Everything in pink is owned
by ops specialists - the
infrastructure that powers the
process
3.Everything in purple is the
shared responsibility of the
whole team
4.Developers commit their
changes to git, and merge their
branches ready for release
5.The automation platform
then continuously packages and
releases changes to one or more
environments

11. Technical
constituents of
DevOps
11
1. Automated unit
testing
2. Version control
4. CI/CD 5. Automated end-
to-end testing
6. Disaster recovery
3. Code
maintainability

12. 1. Automated
unit testing
12
Unit testing is the first step on the path to DevOps adoption.
It’s the most fundamental signal of the validity of the changes
you’re making.
You should run your unit tests:
●Regularly during development
●On every merge or deployment
●Regularly on any orgs in your release pipeline

13. 2. Version
control
13
Version control underpins almost all other DevOps practises.
It’s a fundamental requirement.
A version control system:
1.Tracks changes to files over time
2.Allows developers and admins to work in parallel
3.Acts as a shared source of truth
4.Provides a mechanism for code review
5.Provides a mechanism to integrate team members’ changes

14. 3. Code
maintainability
14
Maintainable code is code that’s easy to read, change, test,
merge, and reuse. Maintainable code contributes to continuous
delivery, reduces technical debt, and as a result, increases
productivity.
You can improve code maintainability by:
1.Encouraging good coding practices
2.Enforcing maintainability rules using static code analysis
tools like PMD and Clayton
3.Use peer review to improve code quality

15. 4. CI/CD
15
Continuous delivery
Releasing changes to end users as soon as they’re available.
Continuous integration
Regularly combining, building and testing everybody’s changes
to validate there are no emergent issues when the changes are
brought together.
Continuous deployment
A means to get closer to continuous delivery - deploying each
merged change to its target environment, as soon as it’s ready.

16. 4. CI/CD
16
CI/CD is a mechanism to automate various parts of the release
process. It’s primarily used to automate:
1.Validation of developer branches pre-merge
2.Static code analysis
3.Preparation of deployment packages
4.Validation of those packages
5.Deployment / promotion of those packages
There are various tools that let you do this, both Salesforce-
specific and more general-purpose.

17. 5. Automated
end-to-end
testing
17
End-to-end testing
Integration testing
Unit testing

18. 6. Disaster
recovery
18
Data in Salesforce is vital to the functioning of the business. The
cost of data loss is at best high, and can be business-ending.
There are myriad causes:
1.A destructive deployment
2.A faulty integration
3.A disgruntled employee
4.A platform issue
OLD LOGO

19. Key aspect : Integrated in your work environment

20. Developers and Admins
Productivity – Speed of Deployment
Quality – Defects
Organization
Risk management
Tracability, Visibility, Understanding
Organization Resilience
Chain of Responsibility, RACI
Focus on Delivering Value
Resource-Budget Optimization
–> orient workload to Value Added
Tasks
Team satisfaction – Employee Experience
(Technical and Business)
Active Change Log Audit (Metadata-data)
Investigations
Benefits
• Do not solve the whole question of the clean design and implementation of all org features
• But is a strong helps to set up best practice / improved strategies, when they are designed and
planned
• (Cf. Agile, CI/CD, DevOps, Architecture …)
Available for change !
Ready to Innovate !

21. Quantitative
ROI
The four key metrics
21
1. Deployment frequency 2. Lead time
3. Time to recover 4. Change failure rate
The number of production
deployments a team performs in
any given day, week, month, or
year.
The average period between the
point a change is committed, and
that change being live in
production.
The average period between an
outage or production defect, and
restoration of normal service.
The percentage of changes
released to production that result
in degradation of service.
Assessment : What would
be yours ?

23. Let Start the Journey
!

24. Qualitative
characteristics
Salesforce’s DevOps journey
24

25. Link with Project or Service Management Practices
Projects
• Project Backlog Management
• Release Management
Support and Incident Management
• Ticketing and Issue resolutions
• Fix and Release Management
• Including : delta analysis in incident resolution
And progressively, implement CI/CD framework and DevOps Culture

26. How to implement ? Who will do this ?
‘Big’ CRM/IT team
• Maintain your own CI/CD environment
• Eventually mixed environment if Integration Partner have also one
• Set up of a clean CI/CD and Lifecycle process
• Nota : link with other components, non-SF, of the system : coherent deployments
Small or non-existing CRM/IT Team
• Rely on SF integration partner environment

27. • Agenda for “CI/CD – DevOps Specific Meeting”
• ?
• Who is interested ?
• - ?
• Who has already done it ? Would like to present something ?
• - ?

28. Thank You