The technical news from Trailhead DX fell into three categories – Continuous Integration/Continuous Deployment (CI/CD), AI/Ml and Event-driven computing. In this post, I will take a quick look at the CI/CD story story.
Salesforce DX is now in open beta. It’s a major upgrade to the way Salesforce code can be developed. The approach borrows heavily from Heroku DX, bringing pipelines for Continuous Integration/Continuous Deployment to Apex and Lightning. Salesforce DX will be used by the ISVs rather than enterprises first. Software companies already generally practice agile development, with automated testing, but Salesforce hasn’t made it easy to use new approaches with APEX and Lightning code.
Salesforce DX introduces a new Command Line Interface (CLI), with the ability to pull down Org (the atomic unit of a Force app is the Org structure) metadata for local development, and a new packaging mechanism. One claimed side effect of moving beyond the “Happy Soup” of objects and calls in traditional legacy Salesforce code, to a more modular approach with automated testing, is that it will be easier for Salesforce and partners to embrace open source.
The Salesforce DX Command Line Interface (CLI) is based on the Heroku CLI. Embracing the Heroku way is really important. Heroku is all about slick developer experience, in many ways it exemplifies modern software development. 12 Factor development was codified by Adam Wiggins, one of Heroku’s founders. The only real question is – what took Salesforce so long to adopt more Heroku developer experience design thinking?
Atlassian and Github are both now creating courses on Trailhead. GitHub is of course on a mission to teach people about distributed version control systems and how to use Git and GitHub to manage source code and work more effectively in teams. Lack of knowledge is GitHub’s biggest competitor. The Atlassian work meanwhile is interesting from an “enterprise software” perspective. If Salesforce is serious about fundamentally changing how organisations build Apex and Lightning apps, it’s going to need partners that specialize in that agile, CI/CD and DevOps. So far the Atlassian relationship only goes so far as writing Trailhead modules. While Salesforce and Atlassian didn’t announce any product integration, that will surely follow – for example managing issues and projects (JIRA), CI testing (Bamboo) and source code (Bitbucket). I would have expected to see more product integration out of the gate – having written recently about the race to pipeline dominance, for example. But getting the tool out there is of course the first step.
Unlike Atlassian, during the keynote Travis CI featured –as an automation tool. Wade Wegner, VP Product Management walked me through his use of Travis CI for pipelines. Salesforce DX also has a test runner for plugging in third party tools, such as Provar –APEX testing. But basically, all of the things could be added to test jobs. See the Lightning Test Service.
Demos with third party tooling included using Travis CI for headless OAuth, to manage keys in the development environment, running scripts and injecting variables. OAuth is a pain to manage, so this was a neat approach. Travis CI can then pick up test runs from tools for Apex or Lightning. Salesforce DX supports Selenium, and Jasmine or Mocha for unit tests.
Salesforce DX is immature, but potentially important. Apex and Lightning both need to be part of the new world of pipelines to have ongoing industry relevance.
Salesforce is a client, paid T&E. Travis CI is also a client.
No Comments