Customer relationship management (CRM) is a vital business competency. CRM is about knowing who your customers are and tracking interactions with them to achieve better business results. Marc Benioff envisioned a way to do CRM differently (and better) with cloud computing. He founded Salesforce.com which is now the top CRM platform in the world as well as a top ten software company. In 17 years, Salesforce.com has evolved from a single, core application to several integrated platforms that support social media marketing, helpdesk automation, custom application development, and mobile systems of engagement.
Intro to Force.com and the Development Tools
Force.com is Salesforce’s PaaS offering which supports custom application development, business process automation, integration into on-premise systems, and other capabilities. The term PaaS refers to platform-as-a-service and has several implications:
- high availability and robustness
- abstraction of the compute, network, and storage resources for an application
- a “bring your own code” model in which the platform simply provides a runtime
- a catalog of services to extend custom applications that run on the platform
Force.com as a platform uses a metadata-driven development model powered by an underlying Metadata API. The metadata is the basis for any Force.com application and basically describes how users will interact with or consume any capability provided by the core runtime. The metadata works in conjunction with other APIs, Apex, and various technologies underlying the platform to allow companies to go beyond point-and-click application development.
The most basic approach for building Force.com applications (customizing metadata) is to use the App Builder tools in the web UI. For large projects with more complex functionality, such as applications you may find on AppExchange, working solely in the web UI is not practical. As a developer then you will either use an editor of choice or the Force.com IDE (preferred). The Force.com IDE is an Eclipse plugin which helps with metadata customization. While the IDE is powerful, it is not intended for migration of significant changes from one environment (org) to another. The Force.com Migration Tool however is an Ant library that is purposefully built for retrieving and deploying metadata in a programmatic way, and from one org to another. The library provides a handful of core operations with several options. Metadata can either be packaged or unpackaged. Ultimately, for companies that want/need to improve their DevOps maturity around Force.com development, the Force.com Migration Tool is essential:
- It lends itself more closely to a multilevel release process.
- It is more consistent and reliable than manual repetition.
- It can be incorporated easily into a continuous delivery pipeline.
- Too many change sets is impractical to deal with.
The Force.com Migration Tool enables you to build great automation. The tool does not offer much visibility, any audit trails, or process enforcement mechanisms however, nor should it. Not all companies need these capabilities but there is a lot of value in centralized visibility and control over all application deployments, and many enterprise IT organizations do need this. ICYMI there is a Salesforce plugin for UrbanCode Deploy that extends the functionality of the Force.com Migration Tool. With the Salesforce plugin for UrbanCode Deploy, you get all the benefits of the migration tool as well as:
- versioning of metadata changes as deployable artifacts
- a graphical process designer for calling migration tool commands alongside any other command
- the ability to define and reference properties in retrieve and deploy commands
- visibility into environment inventory for an application
- integration and consistency with broader deployment policies in the organization
- deployment of metadata directly from SCM via CodeStation
In the remainder of this article, I will take you through getting started with IBM UrbanCode Deploy to retrieve and deploy metadata from Force.com. I assume you have at least a sandbox environment of UrbanCode Deploy and one agent to work with.
First, install the Salesforce plugin for UrbanCode Deploy. The plugin currently provides five steps:
Second, if you do not have it already, download the Force.com Migration Tool after signing in to your Developer Edition org. Developer Edition orgs are free. I also recommend taking a look at the Readme.html in the download and deploying the sample metadata if this is new to you.
ant-salesforce.jar file from the Migration Tool should be copied to the UCD agent machine that will execute the retrieve and deploy commands, or otherwise be downloadable via a link or shell script. For example in my component processes, I have a step to download
ant-salesforce.jar from Box into the working directory which allows me to execute Migration Tool commands from almost anywhere.
Lastly, there are two sources of metadata in general: a SCM repository and an existing organization. When retrieving from an existing organization, you can use the Create Version step to upload the retrieval output as a component version. If you want to obtain source from SCM, this should be configured later in the Component Configuration.
Model the Application and Component
There are different ways to go about this. The approach I recommend is to create a new application with all of your environments (orgs) and model each package as its own component. If you are not using packages or prefer to model things differently, you might create a component for each metadata type as an example. If you have questions about this, please comment on the blog.
Use properties as much as possible. At a minimum, you should define properties for the org URL, username, password, and token at the environment or resource level. You can also define
salesForce.proxyPassword as resource properties as these are default properties in each step. In my test environment, I have the following Resource Property Definitions:
In my Bulk Retrieve step for example, here are the properties I am using:
I ended up with a component process for each step provided by the plugin. In fact, I created a Salesforce component template with the properties above and the processes below to expedite onboarding of future components:
Every process above is of the type “Operational (No Version Needed)” except for the Deploy process. For the processes executing a retrieval, I create an output directory to use as the target then upload the retrieval output as a version of the component:
In the Retrieve step, you must provide a comma-separated list of packages or specify a
package.xml to use as the manifest for an unpackaged retrieval. If retrieving unpackaged components, store
package.xml in SCM then use “Download Artifacts” to download the file, “Retrieve” to execute the retrieval, and “Upload Artifacts” to upload the output to the same component version.
With the Resource Property Definitions above, onboarding new Salesforce packages or metadata components is very simple. Browse to the Resources tab, create a new top-level group for your application’s resources in the Resource Tree, and choose an agent to execute the processes by adding it to the group. Only one agent is needed.
When adding the component to the agent, a pop-up will appear prompting you to define the resource properties:
Using IBM UrbanCode Deploy to govern Force.com metadata migrations is simple and offers several benefits. If you are currently using the Force.com Migration Tool and experiencing bottlenecks or failures in this domain, UrbanCode Deploy is an answer. If you simply want to improve consistency and gain better visibility around Salesforce deployments, UrbanCode Deploy can help. Talk openly with your Salesforce development teams about how they work today and then shift focus towards how to automate those processes in UrbanCode Deploy. Leverage this blog and the IBM forum to post additional questions around specific requirements.