Salesforce CI (Continuous Integration) - SFDX + Bitbucket Pipelines

CI - SFDX + Bitbucket Pipelines
Secure, Simplified and Economical CI

Sat śrī akāl & Namaste
● Abhinav Gupta
● Salesforce MVP (8x) & Architect
● CEO & Founder of concret.io (Salesforce PDO
& ISV Partner)
● I can still code very well, and quite passionate
about it.
● Started with Java in 2004, Salesforce journey
started in 2008.
twitter : @abhinavguptas

Agenda
● What is CI ?
● Why CI?
● Blockers
● Various CI Tools
● Cost Comparison
● Deep Dive into Bitbucket Pipelines
● Bitbucket Tips

CI - “Ki Raula Payea Ehna”?
Why so much noise about it?

Continuous Integration (CI)
● Best Practice
● Central Repo for code/metadata is only “source of truth”.
● All code from each developer resides in that repo.
● Automated Builds to ensure early discovery of bugs/issues.

Still Why - Continuous Integration (CI) ?
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.

What’s biggest blocker?
In getting successful with CI.

Bad Test Case Example
Just for sake of code coverage.
With no assertions of
attributes being correctly
populated in the result.

! Big CI failure !
Even best CI tool can’t help with such quality of test
cases.

● Check intentions to write good quality test cases
● Create positive and negative scenarios
● Try following TDD (Test Driven Development) - OPTIONAL
● We all know Apex could be tested via unit tests.
● Aura and LWC can also be unit tested via Jest, Jasmine, Mocha etc. - OPTIONAL
Good news - Not just Apex, but Aura/LWC unit tests can be auto executed in CI env.
CI Prerequisites for Salesforce

Various CI Tools
External Tools
● Are not part of your repo / git hosting service.
● Setup private/internal hosting, or configure
hosted solution subscriptions.
● Offer limited free build minutes /
concurrency.
● Examples:
○ Jenkins
○ CircleCI
○ TravisCI
Internal Tools
● Offered as part of your repo / git hosting
service.
● No need to setup extra server or hosting.
● No new subscription $$ (most of the times).
● Examples:
○ Bitbucket Pipelines
○ GitLab Pipelines

Quick Cost Comparison
As per pricing details listed 20th July 2019

External CI Tools - Circle CI Costing
https://circleci.com/pricing/

External CI Tools - Travis CI Costing
https://travis-ci.com/plans

Internal CI Tools - Bitbucket Costing
https://bitbucket.org/product/pricing

Internal CI Tools - GitLab Costing
https://about.gitlab.com/pricing/

My preference
Internal CI Tools is my preference for many reason like
- No more extra CI server to configure and worry about.
- No extra subscription to buy and manage.
- No app switching.
- Code / IP is not exposed to external servers, which could be insecure. Specially, CI
tool configured on a poorly secured internal servers.
- Over exposure to all GIT projects, which one might not want to expose to CI.
- One just needs to commit a XML config file for enabling CI.
- 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 projects, with quick
build times and not huge Processing/RAM requirements.

Deep Dive Bitbucket Pipelines
Exploring some key areas, and how tos.

CI - Skills Checklist
● 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.
○ It’s not must, but helps a lot
● Attitude
○ Towards writing good tests, and investing some time in grooming these skills.

Typical CI Flow
Simple CI for starting up
● Code/metadata pushed to a target branch.
● CI System/Bitbucket executes the CI Scripting file, which typically
○ Create new scratch org.
○ Push all the code/metadata to new scratch org.
○ Run tests
○ Deletes the same scratch org.
○ It Optionally
■ Create new package version, attempt install of the package in new scratch org
■ Run tests to ensure stability of the same

Setting up Bitbucket Pipelines for Salesforce (via 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 complete bitbucket-pipelines.yml file, which covers all the steps mentioned in the
previous slide.
It shouldn’t take more than 15-20 mins to configure all of the steps mentioned in the
README.

Careful - About Scratch Org Limits
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
● It’s quite easy to get super excited about CI
and scratch orgs.
● Before planning a CI flow of your fantasy,
please check the table on the right >
● If your customer/partner is not having
enterprise edition org, you need to check
○ Number of developers in team.
○ Frequency of spinning new scratch orgs
in team for hotfixes, bugs and features.
○ CI enabled branches, where auto
scratch org creation will happen, and
what is the frequency.

Purposeful & Sensible CI
● We saw limits on number of scratch orgs one can spin on daily basis.
● It’s quite easy to overdo CI, if applied to all branches.
● Imagine, scratch orgs getting created on commit in any branch.
● It might not be helpful and easily burnup the scratch org limits.
● Add unit testing code in key release branches, like TEST, QA, UAT. Avoid it in hotfix, feature etc.

Purposeful & Sensible CI
Sample script showing feature branches ignored for Auto test runs, and scratch org creation.
pipelines:
default:
- step:
script:
- echo "This script runs on all branches that don't have any specific pipeline assigned in 'branches'."
branches:
master:
- step:
script:
- sfdx force:org:create --targetdevhubusername HubOrg --setdefaultusername --definitionfile config/project-scratch-def.json --
setalias ciorg --wait 10 --durationdays 1
- sfdx force:org:display --targetusername ciorg
#Push source to scratch org
- sfdx force:source:push --targetusername ciorg
#Run unit tests on scratch org
- sfdx force:apex:test:run --targetusername ciorg --wait 10 --resultformat tap --codecoverage --testlevel $TESTLEVEL
#Delete scratch org
- sfdx force:org:delete --targetusername ciorg --noprompt
feature/*:
- step:
script:
- echo "Avoid anything scratch org stuff on feature/* pattern."

Branch Permissions
- Keep feature and other dev
branches open for all.
- Lock WRITE access to sensitive and
final branches like UAT/Prod to a
few responsible engineers.
- They should code review and make
sure no junk is coming in.

- It’s good to document and agree on
a branching model in the team.
- Bitbucket helps with that, by clearly
defining feature, hotfix, bugfix and
release branches.
Branching Model

- How nice it will be to auto assign reviewers on pull requests. (pic below)
Default Reviewers

- REPO variables are used in CI scripting to access various normal and
sensitive data. Bitbucket allows easy masking of sensitive information. Just
check the “Secured” option when adding the variables.
Safe Repo Variables

More control on security
“Deployments” feature allows one to
- Tag env as Test, Staging and Prod
- Have clear separation of env
variables for each of them. Which
are only editable by configured
admins.
- Fine permission control on which
branches, people can deploy to that
env.

Integrations
Allows Bitbucket to talk to your Bug
Tracking or Build System.
This option gives you ready made scripts
to integrate with your Bug tracking or
build tracking system.
Mostly requires copying some API keys
etc and setting up the env. Variable.

Slack / Chat Alerts
It’s no code, a simple OAuth with Slack
will take it forward >

Salesforce example uses
Docker based pipelines
config file. If your
organisation works on
Java, Python and other
language, variety of
sample pipeline config
files are available, which
work easily on gradle,
maven etc.
Multi Language Templates

● Official Salesforce Repo for Bitbucket Pipelines
○ https://github.com/forcedotcom/sfdx-bitbucket-package
● Continuous Integration with Salesforce DX
○ https://developer.salesforce.com/blogs/2019/05/continuous-integration-with-salesforce-dx.html
● Trailhead
○ https://trailhead.salesforce.com/en/content/learn/modules/sfdx_travis_ci
○ https://trailhead.salesforce.com/en/content/learn/modules/heroku-flow/learn-about-continuous-integration-deployment-
and-delivery
References

Salesforce CI (Continuous Integration) - SFDX + Bitbucket Pipelines

More Related Content

What's hot (20)

Similar to Salesforce CI (Continuous Integration) - SFDX + Bitbucket Pipelines (20)

More from Abhinav Gupta (20)

Recently uploaded (20)

Salesforce CI (Continuous Integration) - SFDX + Bitbucket Pipelines