4

Is there any guide on how to setup Bamboo with the Salesforce CLI. We are not using SalesforceDX yet but just want to setup a job to deploy from GIT repo in BitBucket onto a sandbox. I guess the steps would be something like the following

  1. Install the Salesforce CLI in the Bamboo Server which is on a Linux box.
  2. Register the sandbox using sfdx force:auth:web:login
  3. Create the relevant Plan/Tasks in Bamboo.

The parts I am not sure about are:

  • In step 2 I can get this to work in Windows ok but wonder how this will work in Linux as it has to open a browser.
  • In step 3 how to configure the Builder Task in Bamboo
2
  • Just FYI, You can do this using force migration tool(ant) and don’t need Salesforce CLI. – javanoob Oct 31 '18 at 11:47
  • 1
    I am aware of that I was thinking to try and make it future proof for any move to SalesforceDX – scottrm Nov 5 '18 at 10:29
8

Disclaimer: I don't have specific experience with Bamboo, but I've used other CI solutions in situations like this and I think the principles are transferrable.

Your CI jobs won't authenticate to the target environments using sfdx force:auth:web:login because that command always involves user interaction. This is not about Windows versus Linux as such, but about setting up a process that works with no UI. While each CI solution is a little different as far as what the configuration looks like, you'll find the sequence of steps is generally the same.

Sticking with authentication for a minute, it looks like you're not using Ant to do your deployments but SFDX CLI. In that case, you'll authenticate using the headless JWT OAuth flow. Your CI script should issue the command

sfdx force:auth:jwt:grant -u my@username.me -f my_jwt_key_file -i my_OAuth_consumer_key

Generally your JWT private key will be stored in your repo in encrypted form, and your CI will decrypt it using a key stored in an environment variable. This offers you more security than keeping plaintext usernames and passwords lying around.

You'll have pre-seeded your environments with a Connected App and a certificate, the private key corresponding to which is the JWT key field mentioned above. Your OAuth consumer key above will come from that Connected App.

The Salesforce DX Developer Guide provides detailed instructions on how to set up connected apps with authentication via JWT for use in continuous integration. See Authorize an Org Using the JWT-Based Flow and following sections.

Once you've authenticated, again assuming that you're using the SFDX CLI but not scratch orgs or the new source format, you'd deploy your source code to a sandbox by having your CI script issue a command like

sfdx force:mdapi:deploy -d src --testlevel RunLocalTests [as desired] -w -1

That will deploy your Metadata API format-source code and run your tests, waiting as long as needed to execute the command.

Further Reading

  • I have written quite a bit on Salesforce CI using CircleCI. While it's Salesforce DX-specific, the authentication solution will be quite similar.
  • Salesforce provides an example repository for Travis CI, which could also be useful.
  • Trailhead has a good module (again using Travis with SFDX). You can think of your use case as combining the Dev Hub and the scratch org.
  • The Salesforce DX Developer Guide, linked above, has very detailed instructions on setting up JWT authentication for headless CI. Your use case is a little bit different, again, but you can still use the same structures to authenticate to your sandbox instead of a Dev Hub.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.