These slides were focused on Down Under Dreamin event, where a good emphasis was given on explaining CI/CD to wider audience including admins, who are not very comfortable with it. Followed by an overview and walk-thru of Bitbucket setup process via SFDX

1. Simplified CI/CD
flows for SFDX
via Bitbucket Pipelines

2. Hello!
I’m Abhinav Gupta
- Salesforce MVP (8x) & Architect
- Started with Java in 2004, Salesforce journey
started in 2008.
2

3. Agenda
▪ Getting comfortable with CI & CD.
▪ Deciding right CI/CD tool.
▪ Bitbucket Pipelines via SFDX and Scratch Orgs.
3

4. Prerequisite
SFDX
• One can use ANT migration tool, but SFDX with scratch orgs etc makes it very easy and quick.
GIT (VCS)
• Clients like “Source Tree” and many others don’t require a geek level command line expertise.
• Having basic idea of commits, pull, push, branching and pull requests is good starting point.
Scripting / Shell
• Not really, Salesforce team gave a very good script which is good and doesn’t needs editing.
• Basic scripting is not that hard.
Discipline / Process
• A well defined process to use feature and bug branches, and code reviews before the solution is merged
back into master, possibly via QA > UAT branches.
4

5. You must be the change you wish to
see in the world.
- Mahatma Gandhi

6. 6
What is
CI/CD ?

7. Hand raise please!
7
Image by Karen Arnold from Pixabay

8. Remember this Pyramid
8
Continuous
Deployment
Continuous
Delivery
Continuous
Integration
GIT + SFDX

9. What is CI?
▪CI == Continuous Integration
▪Changes are often merged back to the main branch.
▪Validate stability and integrity of app post merge, by creating a
new build and running automated tests against the same.
▪Avoid shocks/surprises/errors, when merged code is build for
release/deployments.
9

10. CI’s Lifeline
▪Top quality unit and other automation tests.
▪No CI tool can succeed with coverage only test cases.
▪ISV’s/SI’s - Adding efforts for unit tests in scope, will build good
relations and less nightmares.
▪Not just Apex unit tests, but Aura and LWC can also be unit
tested via Jest, Jasmine, Mocha etc.
10

11. Bad Test Example
▪Code Coverage Test
only
▪No assertions of
business logic and
results/state.
11

12. Real life
It’s easy
▪ To break one thing while fixing others.
▪ To ignore minor dependencies between components.
▪ To ship the same (in absence of QA, or release pressure).
Imagine this with multi developers, and modules in medium/large scale
projects.
12

13. CD : Delivery vs Deployment
13
Image Source: https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment

14. Deciding
CI/CD Tool
14

15. External Tools
• Not a part of your repo / git hosting
service.
• New subscription ($$)
• Configure private/internal hosting or on
the cloud.
• Offer limited free build minutes /
concurrency.
Examples: Jenkins, CircleCI, TravisCI
External vs Internal
15
Internal Tools
• Are part of your repo / git hosting service.
• No new subscription $$ (mostly).
• No need to setup extra server or hosting.
• Virtual/Docker runtime + Scripts.
Examples: Bitbucket/Gitlab Pipelines, and
Github Actions

16. Internal Tools - Advantage
▪ No extra CI server to configure.
▪ No extra subscription to buy.
▪ No extra login/credentials/permissions to manage.
▪ Code / IP is not exposed to external servers, which could
be insecure. Specially, CI tool configured on a poorly
secured internal servers.
Imagine configuring Jenkins, its required plugins, keeping the
server live, and secure.
16

17. Internal Tools - Advantage
▪ External tools might required access to all GIT projects,
which an enterprise might not want to expose to a 3rd party
CI.
▪ Just commit a XML/YML config file for enabling CI/CD in any
repo.
▪ Git repo auto starts Docker image, and runs the script.
▪ CI results, permissions are well integrated in the repo only.
▪ Bottom Line: Pipelines and internal CI tools are very good for
small/medium projects, with quick build times and not huge 17

18. Bitbucket Pipelines
18

19. Scratch Orgs
Before we move ahead
CI/CD with Scratch orgs and SFDX is quite powerful, yet
simple! i.e.
• Create scratch org (quickly)
• Push code (quickly again)
• Run all tests (Integration checked)
• Create packages (Release) – optional.
• Dispose/delete the scratch org to give a clean slate for next
time.
All this could be done automatically via a simple shell script.
19

20. Bitbucket Pricing
https://bitbucket.org/product/pricing
20

21. Bitbucket + SFDX
https://github.com/forcedotcom/sfdx-bitbucket-package
^ Above open source repo from Salesforce is well documented
example.
It clearly shows:
▪ How to setup connected apps.
▪ Using JWT grants via SFDX for automated/headless
authentication.
▪ A functional bitbucket-pipelines.yml file, with all CI/CD
steps.
▪ It shouldn’t take more than 15-20 mins to configure all of the
steps mentioned in the README.
21

22. Bitbucket Script's key SFDX commands
- sfdx force:org:create: Creates new scratch org
- sfdx force:source:push : Pushes source code in the scratch org
- sfdx force:apex:test:run : Executes Apex test cases
- sfdx force:org:delete: Deletes the scratch org
Optional / Additional Steps
- sfdx force:package:version:create: Creates a new package
- sfdx force:package:install: Installs a given package into an org.
- sfdx force:apex:test:run
- sfdx force:org:delete
22

23. Before we get too excited
23
Edition Active Scratch
Org Allocation
Daily Scratch
Org Allocation
Developer Edition or trial 3 6
Enterprise Edition 40 80
Unlimited Edition 100 200
Performance Edition 100 200

24. Practical CI/CD
▪ Plan CI/CD based on
- availability of scratch orgs on daily basis.
- build minutes available with your pricing plan.
▪ It’s quite easy to overdo CI, if applied to all branches.
▪ Imagine, scratch orgs getting created on commit in any branch.
▪ Add unit testing code in key release branches, like TEST, QA, UAT.
Avoid it in hotfix, feature etc.
24

25. Tuning script at branch level
25

26. GitHub Users
▪ Watch out GitHub Actions.
▪ Currently in BETA, with invite only access.
▪ They are quite powerful and advanced CI/CD solutions.
▪ Probably best of the cult.
▪ Schedule vs Events.
▪ Steps, Actions, Tasks and much more
https://help.github.com/en/articles/about-github-actions
26

27. References
• Salesforce Bitbucket CI/CD Sample Repo:
- https://github.com/forcedotcom/sfdx-bitbucket-package
• Atlassian Blog on CI/CD
- https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
• Trailheads
- https://trailhead.salesforce.com/en/content/learn/modules/git-and-git-hub-basics
- https://trailhead.salesforce.com/en/content/learn/modules/sfdx_app_dev
- https://trailhead.salesforce.com/en/content/learn/modules/sfdx_travis_ci
27

28. Thanks!
Any questions?
You can find me at
▪ @abhinavguptas
▪ abhinav@concret.io
28