Salesforce DevOps Q&A

Interested in becoming a DevOps engineer, but you still have some questions about it? Sebastian V, an architect in our Uruguay office, has answers.

Salesforce DevOps Q&A

What DevOps tools have you come across? Would you recommend any Salesforce-related products?

There are many tools, but the most useful ones are repositories. Then we have different automation tools based on the Continuous Integration approach. The first tool I used was CumulusCI, a powerful toolset for employees and community collaborators. It allows anyone working on an enhancement to NPSP(Nonprofit Success Pack) or EDA (Education Data Architecture)—or even a community project to spin up a Salesforce instance complete with NPSP or EDA already installed and configured.

CumulusCI builds orgs based on repeatable recipes (dependency management, package or application installation, metadata deployment to tailor org, and more). CumulusCI makes it easy to define fully realized scratch orgs. Also, it has a pipeline, a UML script that lets you determine how you want that deployment to be. For example, suppose you need to add test data or run one specific apex class before the deployment. In that case, you can customize the way that you are going to deploy.

Jenkins is the second tool I have been using. Jenkins is a free and open-source automation server. It helps automate software development related to building, testing, and deploying, facilitating continuous integration and continuous delivery. You can integrate it with different tools, like Slack, GitHub, Assembla, and more. It’s an excellent tool. 


Should the production deployment be automated too?

The idea is that we try to automate everything. The thing about production deployments is that sometimes it is an issue because businesses don’t want an automated tool to do those deployments. 

The primary goal of DevOps is to try to automate everything. This is what we call the Value Stream: the process required to turn a business hypothesis into a technology-enabled service that provides value to the customer.


Does CumulusCI use the same SalesforceDX commands?

No, it doesn’t use the same ones. For me, SalesforceDX (SFDx) commands are more difficult to understand because of the way they are written. CumulusCI gives you more human-readable commands, and it lets you create your own commands.


How different or similar are the profiles of a DevOps engineer and developer? Do DevOps engineers need to be a developer first?

In the past, operations teams have had a different role in IT. DevOps is not trying to change that because there are some things that the operation team needs to continue doing, like monitoring. The DevOps profile adds development, so if you ask me, you can start from both sides.

It is essential to mention that being on the DevOps side requires knowing code because pipelines are written with code. For example, Jenkins pipelines are written in a groovy version of Java. Also, command-line tools use shell commands, so it is better if you know how to write shell commands.

So most DevOps engineers must understand and know how to work with GIT, shell commands, and different languages like Java. 


What should I do if I want to get started in DevOps?

You can follow many paths, and there’s the myth that DevOps engineers are the top senior developers, that is not like that. DevOps has a broader spectrum. And, of course, there are DevOps engineers that are awesome!

But if you want to be a DevOps engineer, we are not interested in designing applications; we focus on helping improve the development lifecycle. You can take some great certifications online, like AWS Certified DevOps Engineer – Professional and Certified Kubernetes Application Developer (CKAD). They’re a great way to get started.


How is DevOps different from agile?

That’s the myth that says that DevOps is coming to eradicate agile. That is a lie because DevOps and agile complement each other. Agile focuses on the requirements side and the building part, while DevOps focuses on what comes next – it’s like an extension of the framework. DevOps tries to focus on the value streams, how they can reduce them, and how to automate. So it’s like the next step in the new era of a software engineer. You still need agile, a scrum master, a product owner, and your team. But how do you deliver that to the market? Well, you will have to use DevOps. 


What is the best thing about DevOps?

Our DevOps team keeps growing, so we asked some of the team members for their favorite things about DevOps:

“What I like the most about DevOps is the interrelationship with all teams in general. One is a full stakeholder. The most important thing to know and remember is that DevOps is not a trade, profession, or specialty; it is a philosophy and culture, and it is not only the knowledge about the use of tools. At the same time, a DevOps engineer never stops learning. We are constantly learning new tools and ways of working from different resources. Another exciting thing is the automation of processes to launch servers, monitor them, and generate an infinite number of jobs in this area. I can’t select one favorite tool because I like them all. I use the IntelliJ IDE and Infrastructure As A Code (IAAC) Terraform + Ansible + Puppet + Salt for programming. For CI/CD, I use Jenkins + Github. DroneCI for image generation, for acceptance test Cucumber, and for monitoring Sonarqube.” 

Marco Ramirez – Oktana DevOps, Bolivia

“I like being able to have a precise and efficient process of moving the new ‘features’ implemented to other environments. So later, as a developer, you can focus on the development itself and not worry too much about deploying the new features.”  

Kevin Monzon – Oktana DevOps, Uruguay

If you are interested in learning more about DevOps, read our latest article: Introduction to DevOps and Continuous Integration. And if you are interested in joining our family and following this career path, check out our open positions.

Test Automation & Continuous Integration with Salesforce DX

Meet the Salesforce Developer Experience, Salesforce DX

Salesforce DX provides you with an integrated, end-to-end lifecycle designed for high-performance agile development. Learn how to integrate the Salesforce DX with automation framework and Jenkins to automate testing and achieve continuous integration.

Before you get started

Ensure you have these things set up so you can follow the steps of this module:

If you’ve completed the App Development with Salesforce DX Trailhead module, likely you already have the tools you need to complete this module. If you’re unsure, we recommend heading over to Trailhead first.

What is Continuous Integration?

Continuous integration (CI) is a software development best practice. When using CI, all code that development teams produce is merged into a central repository, where an automated build can validate it. This practice helps development teams detect problems, identify bugs, and allows them to fix them before releasing changes to their customers.

CI is like an insurance policy. Would you risk driving around town without car insurance? No way! In today’s world of agile development, it’s easy to push changes to your orgs. With a CI system in place, even the smallest change is processed to ensure your system continues to work flawlessly. Early detection and fixes are key for happy software stakeholders.

So now you know that CI can help your company save money. Next, we’re going to walk you through the steps to set up CI with Salesforce DX.

Continuous Integration with Salesforce DX

When using automation, it is preferable to create a disposable environment (like a scratch org) to test specific code/changes instead of introducing these changes to a shared org. Salesforce CLI allows you to automate the creation of scratch orgs as part of your CI process. Another cool feature is that Salesforce CLI enables you to completely script all these tasks in the CI configuration file whether you are using org-based or package-based development.

What is a Salesforce scratch org?

A scratch org is a dedicated, fully configurable, and short-term Salesforce environment. 

It allows developers to emulate different Salesforce editions with different features and preferences playing a critical role in development productivity and collaboration. They can also be used as part of automation testing and the implementation of a full CI suite.

It is possible to share the scratch org configuration file with other team members, so everyone can have the same basic org.

Scratch orgs increase developer’s productivity and collaboration during the development process, and facilitate automated testing and continuous integration. You can use the CLI or IDE to open your scratch org in a browser without logging in.

Note: If you try to just install the Salesforce CLI and run Salesforce DX commands, you’ll find quite a few commands will first need you to authenticate into a Dev Hub. This functionality is what allows you and your team to create and manage scratch orgs.

What is a Salesforce Dev Hub?

A Dev Hub provides you and your team with the ability to create and manage scratch orgs. Scratch orgs are temporary Salesforce environments where you do the bulk development work in this new source-driven development paradigm.

To get started with scratch orgs, you choose an org to function as your Dev Hub. While you can enable Dev Hub in any paid org, it’s always best to practice somewhere other than production. Instead, go ahead and enable Dev Hub in a Developer Edition org or Trailhead Playground to use with this module.

  • Can be your Dev or Prod Org.
  • Used to manage/track Scratch Orgs.
  • Link Namespaces to your orgs.
  • Create and manage second-generation packages
  • Is disabled by default. Once enabled, can’t be disabled.

Understanding the Salesforce Development Process

Diagram of Salesforce development process: Org based vs. source/package development
  • Org based model, in which as the name indicates, orgs are the source of truth. Almost the same as the previous models but this time changes are developed and released through Ant migration, metadata API deploy and retrieve.
  • Source/Package development, which is SalesforceDX’s way of development, we are going to use the new scratch orgs in which changes are developed using Salesforce DX CLI (source push/pull commands) and are then released using Metadata API Deploy. In this case we switch from Org Based to Source based, this way our source of truth is going to be our VCS i.e github, bitbucket, assembla.

It is important to note that instead of the traditional Org based development model, where development is done in sandbox/developer orgs then source code is pulled from such orgs to be stored in the metadata API format, a package based development model is recommended using the Salesforce DX project and scratch orgs. 

That being said, moving away from the org-based development model doesn’t mean that you don’t need proper environment management, it’s just the developers’ org that are replaced with scratch orgs. Integration and QA testing is also done in scratch orgs while the validation, testing, and UAT continues to happen in their dedicated sandboxes. In this scenario we may still want to use DevPro Sandboxes to perform some types of testing like Load testing.

Let’s get started!

Let’s go through our preconditions:

  1. Install Salesforce DX – CLI (using NPM):
    • npm install sfdx-cli –global
    • sfdx –version
    • sfdx –help
    • sfdx force:auth:web:login -d -a DevHub (Used to login to your DevHub)
    • sfdx force:project:create -n MyProject –template standard (to create an standard clean SFDX project)
  2. Enable your DevHub:
    • Log into your Org.
    • Setup > Search Dev Hub
    • Enable Dev Hub!
    • Dev Hub available in: Developer, Enterprise, Performance, and Unlimited Editions.
  3. Start Creating Scratch Orgs:
    • Define your project-scratch-def.json file
    • sfdx force:org:create -f project-scratch-def.json –set default username (to create a scratch org based on your `definition` file.
    • sfdx force:org:list (to list all your linked dev hub and scratch orgs)
    • sfdx force:org:display (to display data of your scratch org)
    • sfdx force:source:push (to push code to the org)
    • sfdx force:source:pull (to pull code from the org)

Note: On project-scratch-def.json, probably the most important file to start with for scratch orgs it this. Here we can define what the shape of the scratch org is. Whether we want to enable chatter, or lightning or multi-currency, usually you login, go to setup and enable all those, here we can define all the different preferences and features we want on our scratch.

Jenkins Setup

Jenkins is an open-source, extensible automation server for implementing continuous integration and continuous delivery. You can easily integrate Salesforce DX into the Jenkins framework to automate Salesforce applications testing against scratch orgs.

To integrate Jenkins, we assume:

  • You are familiar with how Jenkins works. You can configure and use Jenkins in many ways. We focus on integrating Salesforce DX into Jenkins multibranch pipelines.
  • The computer in which the Jenkins server is running has access to your version control system and to the repository that contains your Salesforce application.

Before integrating your Dev Hub and scratch orgs into your existing Jenkins framework, configure your Jenkins environment. Our example assumes that you’re working in a package development model.

  1. In your Dev Hub org, create a connected app as described by the JWT-based authorization flow. This step includes obtaining or creating a private key and digital certificate.
    Make a note of your consumer key (sometimes called a client ID) when you save the connected app. You need the consumer key to set up your Jenkins environment. Also have available the private key file used to sign the digital certificate.
  2. On the computer that’s running the Jenkins server, do the following:
    • Download and install Salesforce CLI.
    • Set the following variables in your Jenkins environment by going to Credentials > Select your project folder > Global Credentials > Add New Credentials:
      1. HUB_ORG (DevHub username ID) – Kind: Secret Text
      2. CONNECTED_APP_CONSUMER_KEY – Kind: Secret Text
      3. JWT_KEY_FILE – Kind: Secret File  
      4. Repo access credentials (GitHub Username and Password)
    • The names for these environment variables are just suggestions. You can use any name as long as you specify it in the Jenkinsfile/Build process.
      You can also optionally set the SFDX_AUTOUPDATE_DISABLE variable to true to disable auto-update of Salesforce CLI. CLI auto-update can interfere with the execution of a Jenkins job.
  3. (Optional) Install the Custom Tools Plugin into your Jenkins console, and create a custom tool that references Salesforce CLI. The Jenkins walkthrough assumes that you created a custom tool named toolbelt in the /usr/local/bin directory, which is the directory in which Salesforce CLI is installed.

Jenkins Build

Now we have to specify on Jenkins the steps needed to build our project, create our scratch orgs and run our tests:

  • On your Jenkins project > Click Configure 
  • Add your repository credentials on Source Code Management section:
  • Set build triggers:
    • For CI, Jenkins should be triggered every time a change is merged to your branch (H / 5 * * * * means it will pull changes every 5 minutes)
  • Enable Xvfb so jenkins can run graphic interfaces (for UI tests):
  • Bind your previously created environment variables:
  • Set Custom tools (Salesforce DX previously installed).
  • Provide Node and NPM if needed.
  • Add a build step:
    • Execute Shell:
  • Add post-build steps if needed, we will use junit and allure reports on this:
  • Click Apply/Save button
  • Go to your project and click the Build Now button
    • It will start building your project following the steps you specified on the ‘Execute Shell’ window.
    • You can open the execution console and see the progress
    • If you added post build steps they will be executed accordingly.

That’s it!

If you followed all the steps you should be able to run your Salesforce DX Project, Automation framework, and Jenkins to automate testing and achieve Continuous Integration!

Learn more about Salesforce development from our team, or check out our testing services.

Gathering Leads with Royal Caribbean

At Oktana, we’re heavily invested in the world of mobile app development. We believe that building new mobile tools that let our customers interact with their Salesforce instance out in the field is essential to the future of the platform. One of the most recent projects that allowed us to utilize our Mobile development skills is our project with Royal Caribbean for their Celebrity Cruises premium brand.

Celebrity Cruises participates in a number of large conferences and expos every year where their sales team is out in the field talking to potential clients and customers. They needed a way to easily gather data from the people they met for giveaways and potential sales leads. Additionally, this needed to be a tool that would allow them to gather the data while offline and then sync with Salesforce when they reconnected later because while moving around at conferences they can’t count on network connectivity.

Oktana was brought in to build an iPad app that would accomplish these goals. The app was built and designed internally by us. We designed an app that was slick and would be impressive looking so that when potential customers saw it on the floor it would look like something you would expect from a premium brand like Celebrity Cruises. We needed to make sure it met all of the client’s needs from beginning to end which included both the technical aspects and the app’s appearance.

What tools did we use to accomplish this task? We built the app using Salesforce DX along with Forcereact and the Salesforce Mobile SDK. The app also talks directly to the Salesforce Sales and Marketing Clouds. When a member of the sales team at Celebrity Cruises is preparing to go out to the floor of a show or conference they simply need to launch the app and select the Salesforce campaign the leads will be entered into. Then when they disconnect from the network the app will store all their leads locally and when they reconnect to the network at the end of the day it will sync them with the proper campaign. Additionally, when leads are entered the team member has the option to edit them for errors or even delete them before they sync to keep their campaign list clean.

This project was a perfect fit for us because it allowed us to utilize our experience in mobile development and Salesforce to make a unique tool for our client. The key elements to highlight for this project include:

  • Salesforce DX
  • React Native
  • Salesforce Mobile SDK
  • Apex
  • Sales Cloud
  • Marketing Cloud
  • iOS
  • UI/UX Design

While we have been working on this project for Celebrity Cruises we have also been helping Royal Caribbean with ensuring their tools meet GDPR requirements in the EU. We created tools to ensure collected data could be anonymized upon request. Royal Caribbean has been a great partner for us at Oktana and we believe this app was a great showcase of our skills in both Salesforce and Mobile development.

If you are a Salesforce partner looking to partner with experts to help you provide the best custom app development solutions to your clients Contact us. Our team will give you more information about these services.