Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Salesforce CI (Continuous Integration) - SFDX + Bitbucket Pipelines


Published on

Exploring Salesforce Continous Integration options, with external and internal CI Tools like CircleCI, TravisCI, Bitbucket, Jenkins, and Gitlab.
What are the best practices when planning to go for CI in Salesforce, like
- Active Scratch Org Limit
- Which branches to pick for running CI scripts
- Cost and security of external vs internal tools.
- Branch Permissions
- Other hidden features like integrations, env variable, etc.

Published in: Technology
  • Be the first to comment

Salesforce CI (Continuous Integration) - SFDX + Bitbucket Pipelines

  1. 1. CI - SFDX + Bitbucket Pipelines Secure, Simplified and Economical CI
  2. 2. Sat śrī akāl & Namaste ● Abhinav Gupta ● Salesforce MVP (8x) & Architect ● CEO & Founder of (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
  3. 3. Agenda ● What is CI ? ● Why CI? ● Blockers ● Various CI Tools ● Cost Comparison ● Deep Dive into Bitbucket Pipelines ● Bitbucket Tips
  4. 4. CI - “Ki Raula Payea Ehna”? Why so much noise about it?
  5. 5. 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.
  6. 6. 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.
  7. 7. What’s biggest blocker? In getting successful with CI.
  8. 8. I don’t know CI, GIT etc.
  9. 9. I don’t care about this.
  10. 10. Quality of Automated Tests
  11. 11. Bad Test Case Example Just for sake of code coverage. With no assertions of attributes being correctly populated in the result.
  12. 12. ! Big CI failure ! Even best CI tool can’t help with such quality of test cases.
  13. 13. ● 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
  14. 14. 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
  15. 15. Quick Cost Comparison As per pricing details listed 20th July 2019
  16. 16. External CI Tools - Circle CI Costing
  17. 17. External CI Tools - Travis CI Costing
  18. 18. Internal CI Tools - Bitbucket Costing
  19. 19. Internal CI Tools - GitLab Costing
  20. 20. 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.
  21. 21. Deep Dive Bitbucket Pipelines Exploring some key areas, and how tos.
  22. 22. 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.
  23. 23. 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
  24. 24. Setting up Bitbucket Pipelines for Salesforce (via SFDX) ^ 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.
  25. 25. 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.
  26. 26. 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.
  27. 27. 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."
  28. 28. Some Bitbucket Tips
  29. 29. 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.
  30. 30. - 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
  31. 31. - How nice it will be to auto assign reviewers on pull requests. (pic below) Default Reviewers
  32. 32. - 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
  33. 33. 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.
  34. 34. 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.
  35. 35. Slack / Chat Alerts It’s no code, a simple OAuth with Slack will take it forward >
  36. 36. 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
  37. 37. Thanks
  38. 38. Q & A
  39. 39. ● Official Salesforce Repo for Bitbucket Pipelines ○ ● Continuous Integration with Salesforce DX ○ ● Trailhead ○ ○ and-delivery References