Before we jump into the DevOps process for Salesforce or how we can apply DevOps to Salesforce applications, we will first have a look at how typical or traditional Salesforce development is done in organizations.
In this chapter, we will learn about the traditional development process of Salesforce applications. There will be an overview of some Salesforce concepts such as the sandbox, including the different types of sandboxes and how they are differentiated from each other. We will see the development process of the Recruiting application, which is our sample application, and explain Salesforce concepts. We will also discuss the technical challenges we face in the development, deployment, and delivery of Salesforce applications. We will discuss the life of a Salesforce developer without DevOps and the need for DevOps.
In this chapter, we will learn about the following topics:
- The typical Salesforce development process (without DevOps)
- Sandboxes
- Eclipse for Salesforce development
- Business and technical challenges
- The need for DevOps
Salesforce development is different from other stack development platforms. Everything you need to develop an application is available on the cloud. There is no need to install any software. The main drawback of sandbox-based development is that a sandbox does not provide versioning of your code. So, if someone overwrites your code, then you cannot get a previous version of the code. This causes a big mess in large projects where multiple developers are working on the project.
We will start development by creating our own Salesforce Developer Edition account for free. Register with Salesforce for a free-tier account and test it out. Here are some guidelines for new Salesforce users to create their own Salesforce application using https://developer.salesforce.com/signup:
- Log in to your Salesforce account and provide your username and password.
- Go to setup on top-right corner of your screen. Search for
Appsin theQuick Findbox then selectApps. You will see the welcome page for apps. On the welcome page, you will see some apps that are enabled for your organization. - We want to create a new application. Click on the
Newbutton. As you are a new user, selectCustom App. EnterRecruitingas the app label name. An app is a collection of tabs that are used to create functionality. Users can switch between apps:
- On the next screen, you can choose the image that will be used as the application logo. For testing, you can use the default image or upload an image of your choice. You can change it later on.
- The next screen lets you specify which tabs you want to see on your application. There are already some standard and custom tabs available for you to choose from, or you can create your own custom tabs. For the sample application, you can accept the default and move to the next page. The
Hometab will be present as the default tab.
- On the next screen, you need to choose the user profiles that will have access to this application:
- Make it visible to the
Standard UserandSystem Administratorprofiles. - Save it and it's done.
There are two ways to deploy code to test in a sandbox or production environment:
- Change sets: A change set is used to move changes from a development sandbox to a production environment. Change sets do not contain data. Change sets are best for deploying the same components to multiple organizations. Change sets are good for small deployments, but not preferred for large deployments. The Force.com Migration Tool can be used for large deployments as deployment components can be easily managed.
- Force.com Migration Tool: Using the Force.com Migration Tool requires some setup. It is scriptable, so it is used for a multistage release process, where we can easily have scripted retrieval and deployment of components. Repetitive deployments using the parameters can be done. We can retrieve all metadata in the organization, make changes using the editor, and deploy the same subset of components.
No versioning is provided in a sandbox environment, so it becomes difficult when multiple developers are working on a project and are not in sync. Keeping track of all changes in project can look like finding a needle in a haystack. Deployment with a change set is not recommended for large projects and creating a change set is not scriptable. So it becomes a repetitive task.
The Force.com Migration Tool is good for large projects, but we do not have versioning, so we cannot revert code to its previous version. Also, we are not able to track changes done by developers.
We have different environments, such as development, test, stage, and production, in almost all technical stacks. In Salesforce, we use a sandbox for development and test environments. Sandboxes come in different types as per our requirement, and we can choose which sandbox to use. Let's look at the different types of sandboxes.
"Sandbox is copy of your production organization that contains the same configuration information or metadata, such as custom objects and fields, process builders, flows, and so on."
A sandbox is similar to the dev, test, and stage environments in other technology stacks. They are mainly used for the development of Salesforce applications and testing of newly developed features. We do not want to make changes in the production environment directly without testing it thoroughly. So we need these different types of sandboxes; depending on what we can do with them, we can choose which one to use. Some sandboxes only have metadata from production, and some may have both metadata and data in them. Sandboxes also vary in size. Let's see how they differ.
A sandbox is used to develop and test applications. Depending on the type of sandbox you use, it may also include a copy of the data from your production organization. A sandbox is completely isolated from the production organization, so any changes the developers make won't compromise the data, applications, or day-to-day activities of the other users in the production organization. It is ideal for developing complex customizations to minimize risks.
There are various types of sandboxes:
- Developer: A Developer sandbox is used for development and testing. It provides a separate environment for coding and testing changes done by developers. According to Salesforce standards, one Developer sandbox should be used by one developer for coding at a time, but it is possible for multiple developers to log in at a time. However, a Developer sandbox does not keep track of changes done in it so there are lots of possibilities that developers may overwrite each other's code. A Developer sandbox has a copy of metadata from production. It does not contain data.
- Developer Pro: A Developer Pro sandbox is also used for development and testing purposes, but this sandbox comes with increased storage size. Because of the increased storage size, this sandbox can handle more development workloads and can be used for data load and integration testing.
- Partial Copy: A Partial Copy sandbox contains all the metadata from your production organization, and it also contains a sample of the production organization's data, which is defined in the sandbox template while creating a Partial Copy sandbox. As this sandbox contains sample data, it is mainly used for testing purposes. We can use a Partial Copy sandbox for development, testing, and even for training purposes. Most people do not recommend them for load testing purposes.
- Full: A Full sandbox is a replica of your production organization. It contains all the metadata and data from the production organization. It contains all data, which includes records, attachments, and so on. You can use sandbox templates to decide which data to copy from the production organization to the Full sandbox, depending on which testing operations you want to perform. A Full sandbox can be used for many purposes and supports load testing, performance testing, and staging. It is difficult to use a Full sandbox for development because it needs a long refresh interval.
First, we will go through how we can use Eclipse for Salesforce application development. We will start from the very basic steps, such as installing Eclipse and Force.com IDE, followed by configuring Git with Eclipse.
We will start by installing Eclipse on the developer machine. To install Eclipse, you should have a minimum of Java 6 installed. If it is not installed, you can install it from the official website at https://java.com/en/download/.
We are going to install Eclipse Neon. Java version 7 is required for Eclipse Neon.
The following are the prerequisites for a development environment for Salesforce:
- Operating systems:
- Windows 7, 8, or 10
- macOS 10.7, 10.8, 10.9, 10.10, or 10.11
- Ubuntu 12.04 LTS or 14.04 LTS
- Java SE Development Kit (JDK), Runtime Environment 8 or later (Java download page).
The installation steps are as follows:
- Eclipse 4.5 or later is recommended. Go to the download site at https://www.eclipse.org/downloads/.
- Select the appropriate executable package for the operating system you are using.
- Once the download is complete, you can proceed with Eclipse installation. Double-click on the
.exefile if you are using Windows. - The
Eclipse IDE for Java Developersdistribution is the recommended installer. - Choose an installation folder for Eclipse and click on
INSTALL. It will take some time to install Eclipse. - After completing the installation, launch Eclipse. Select the workspace for Eclipse.
- You will see the welcome page for Eclipse.
Now we have installed Eclipse on our system, we can move forward with the installation of Force.com IDE.
The following are the steps to install Force.com IDE:
- Launch Eclipse, go to the
Helpoption and choose theInstall New Softwareoption from the drop-down list:
- Click
Add. - In the
Add Repositorydialog, set the name toForce.com IDEand the location tohttps://developer.salesforce.com/media/force-ide/eclipse45:
- Click
OK. - If you are not using Java 8, then deselect
Show only the latest versions of available software, and it will show an older version of the plugin. - Eclipse will show a list of all available plugins. Select the
Force.com IDEplugin, and then clickNext. - In the
Install Detailsdialog, clickNext. - Review the licenses, accept the terms, and click
Finish. - Eclipse starts downloading Force.com IDE and installs it and other required dependencies. Once the installation is completed, you need to restart Eclipse to reflect the changes. Click
Yes.
- When Eclipse restarts, select
Window | Open Perspective | Other. SelectForce.comand then clickOK:
We are done with setting up the Salesforce development environment in Eclipse.
We have a Salesforce application, and we want Salesforce code in the local workspace we just created using Force.com IDE:
- Right-click on the
Package Explorerarea, then chooseNewand selectForce.com Project:
- Create a new Force.com project. You need to provide details about your project. Enter the
Project nameandOrganization Settingsdetails for connection:Username: Provide a username and append the sandbox name to it.Password: Provide a password for the given username.Security Token: You need to provide a security token for the sandbox.Environment: Choose the environment you are using, such as sandbox or Production Edition:
Once you have filled in all the details, click
Next.
We will get all the code in Eclipse from Salesforce. Now, whatever changes a developer makes in Eclipse will be in sync with the sandbox being used.
Following traditional methods for the deployment of Salesforce projects is time-consuming. Also, the major problem is with versioning of code, which causes issues in every environment. A particular feature may run perfectly in a Developer sandbox, but we might face issues in production. Tracking every change done by developers and administrators is very difficult, so the miscommunication between teams can result in failed deployments or delay in product delivery.
We can consider scenario where a particular feature needs to be launched as soon as possible and we are facing deployment issues. We may not able to resolve it in time and this will impact on our customers and business as well. We will face challenges such as the following:
- Failed deployments
- Unable to track issues
- No code coverage
- Failed test cases
We need to streamline all these issues and have one solution which will solve almost all problems; here, DevOps comes into the picture!!
Yes, we can apply DevOps practice to Salesforce projects and achieve continuous integration and deployment, and continuous testing for Salesforce projects as well. In DevOps, we have a rich toolset that can also be used for Salesforce projects.
Let's try to cover this step by step. The first and most important consideration is how we can achieve versioning in Salesforce where the Salesforce sandbox itself doesn't keep versions of code stored. A Salesforce sandbox stores only a minimal amount of information about changes, such as which user made the previous change and its timestamp. Obviously, this information is not enough to achieve full versioning. We can use a very popular source code management tool, Git for Salesforce projects, where the sandbox will be in sync with the Eclipse workspace and Git repository.
Salesforce provides a very useful tool for migration of metadata from a local repository to a sandbox, which is the Force.com Migration Tool. The Force.com Migration Tool is an Ant-based tool for moving metadata from a sandbox to local repositories. With the Force.com Migration Tool, we can perform operations such as retrieving metadata from a sandbox and deploying metadata to a sandbox.
Using this Force.com Migration Tool with Jenkins, we can build our continuous integration jobs. Jenkins is an automation server that allows us to automate tasks such as building, testing, and deploying software on a particular environment. Jenkins is written in Java programming language and allows us to create continuous integration jobs. In later chapters, we will see how to use the Force.com Migration Tool with Jenkins and automate continuous integration tasks in Salesforce projects.
Finding issues can be like finding a needle in haystack. We need to track issues in our project. There are many applications present that we can use in our projects, such as Bug Tracker and Jira. This helps us to get an idea about issues in our project and in which environment they are present; also, it helps us be on track and stay updated. We will see some of these applications in detail in later chapters. We will also see how we can integrate these tools and have a CI-CD pipeline for Salesforce projects.
Achieving continuous testing with Salesforce is possible with the help of tools such as Selenium and Qualitia. Selenium is a testing framework that is used to test web applications. Qualitia is a scriptless automation tool that helps to create test cases without writing scripts/code.
Do you still have doubts about applying DevOps to Salesforce? The answer can be positive or negative, but, wait, do not mark it as your final answer because you have still to read the following chapters, where we will try to provide a clearer idea about using DevOps tools for Salesforce projects. Also, we will cover some examples and real-time scenarios about DevOps and Salesforce, so stay tuned!
In this chapter, we got an overview of the traditional Salesforce development process, which environments are used for Salesforce development, and how we can set up a Salesforce development environment with Eclipse and Force.com IDE. Also we looked into sandboxes and the types of sandboxes used in Salesforce projects, and how they differ from each other.
We also got some information about traditional deployment methods used for Salesforce projects, such as change sets and the Force.com Migration Tool and discussed which method is suitable for small and large projects. We also looked into technical and business challenges in Salesforce.
In the next chapter, we will see how we can apply DevOps for Salesforce projects. We will compare other technical stacks with Salesforce and see how applying DevOps to Salesforce is different than DevOps in other technical stacks. We will also discuss various ways to apply DevOps to Salesforce.
