Introduction to Developing Commercial Apps on Force.com
The process of building and distributing commercial applications on Force.com is different than the process of building and distributing commercial applications using traditional software development technologies. For example, your applications run in the cloud, you can move them between online environments by treating them as metadata, and you can package them for simple click-only installation and license management. This article describes what the application development process looks like on Force.com. It describes how your team can add additional developers to an in-progress development project, and how your team can use version control in your development process.
ISV Development vs. IT Development
This article is focused squarely on teams that are developing applications to be sold to external customers. These teams are sometimes referred to as "Independent Software Vendors" or "ISVs". ISV development teams will use processes that are somewhat different from what IT development teams will use. That’s to be expected, as the goals and needs of external customers and in-house business partners are also different.
If you’re an IT Architect, Administrator, or Developer, you should read the Development Lifecycle Guide. It is an outstanding resource for IT teams that are using Force.com to improve the way their organization works. It describes Release Management, the Application Lifecycle, Development Environments, Tools, Testing, Deploying to Production, and more – all from the perspective of an IT team.
If, on the other hand, you’re developing an application on Force.com, and you plan to distribute that application to as many customers as possible, then you should continue reading this article. After finishing this article, I encourage you to read the Development Lifecycle Guide as well - it does contain information that is universally useful for ISV development teams as well as IT development teams. Just keep in mind that some of the topics in the Development Lifecycle Guide will not be applicable to ISV development teams.
One immediate difference between ISV development and IT development is that ISVs will not use Sandbox environments for development purposes. Instead, you will use Developer Edition orgs - which we will discuss in additional detail later on in this article. Another major difference between the ISV and IT development processes is that at the end of a development cycle, you will create a managed package that will be distributed to your customers. IT teams don’t create managed packages.
The ISV Team Development Process
There are a few things that your team is going to need to set up in order to facilitate working together to build your first Force.com app. First, each developer will need to be able to add functionality to the same application independently of one another, so everyone will need to create a workspace that is isolated and independent from everyone else’s. Second, you will want to keep in sync with changes made by everyone else on your team, so you will need to set up a source code control system. Third, you’ll want to install the Force.com IDE – it’s a great development environment, and it will provide you with a convenient platform for checking in changes to your source code control system. And finally, you will need to integrate everyone’s code and create a managed package. For that, you’ll need to create an integration / packaging environment. Putting everything together, your development process should look something like this:
Selecting a Development Environment
Let’s start at the very beginning of this process – choosing a development environment. Since your ultimate goal is the creation of a managed package, you will need to use Developer Edition orgs. Only Developer Edition or Partner Developer Edition environments can create managed packages.
Individual Developer Edition vs. Partner Developer Edition
ISVs have a couple of Developer Edition options. You can sign up for a normal Developer Edition org at Developer Force. Alternatively, you can also become a registered partner. By doing this, you will be granted the ability to provision "super-sized" DE orgs. Here is a high level comparison of the two:
|Development Environment||User Licenses||Data Storage||API Enabled*||Notes|
|Developer Edition|| 2 full CRM licenses|
3 Force.com Platform licenses
| 20 MB |
(about 10,000 records)
|Yes||Sign-up is Free!|
|Partner Developer Edition¹|| 20 full CRM licenses|
20 Force.com Platform licenses
| 250 MB |
(about 125,000 records)
|Yes||This is a DE org with more storage, features and licenses. Free for enrolled partners.|
1 Available for registered Force.com ISV and Consulting Partners
To better understand the advantages of the different org types, I recommend reading An Introduction to Environments.
The Force.com IDE
Regardless of which type of DE org you use for development, you'll want to use the Force.com IDE. Based on the Eclipse platform, the Force.com IDE is a powerful client application for creating, modifying and testing Force.com applications. It provides a comfortable environment for programmers familiar with integrated development environments. And since Eclipse supports a variety of source code control plugins, your team will be able to easily stay in sync with each others changes.
Managing Source Code
Source code control is a critical component of team development. And luckily, the Force.com IDE is built on Eclipse, so it supports the most popular source code control systems. Subversion is a popular one, and adding an existing Force.com project to a Subversion repository is straightforward. Alternatively, if you want to set up your own Subversion repository, there’s a tutorial for how to create your own Subversion server and use it with Force.com projects as well. The specific source code control system that your team uses is not nearly as important as is integrating source code control in to your development process.
Replicating Development Orgs for Additional Developers
One common task that your development team is likely to encounter is creating additional development orgs. For example, if you add a new developer to your team, you'll want to create a new development org for her. Luckily, Force.com doesn't require you to purchase, configure and manage additional servers and software. Instead, you'll need to perform just three actions:
- Create a new Developer Edition org
- Replicate metadata components from source control to the destination org.
- Replicate test data to the destination org.
We have already covered the selection of development environments, so let's jump in to replicating metadata. There are a number of ways to replicate metadata between orgs. You can use the Force.com IDE, you can use the Force.com Migration Tool, or you can use a source code control system. The most repeatable method of replicating metadata to additional orgs is to use a source code control system.
If you have been using Subversion as your source code control system, and you have already added your application to to it, then you can follow the How to Checkout Force.com Metadata From Subversion instructions to replicate your team's metadata to a new org. If you’re using a source code control system other than Subversion, the process should be similar.
After checking out the metadata from your source code control system, you may still need to configure a few settings in your new development environment by hand if they are not included in the list of supported metadata components.
One important thing to be aware of is the method of propagating destructive changes. I've created a separate document that outlines the steps required: Propagating Destructive Changes.
Also, one other best practice is that you should avoid including your package's namespace in your source code. If you only deploy to your packaging org, and never retrieve metadata from your packaging org, you should be able to follow this best practice without issue. There are a few corner cases where you will need to include a namespace, but they are rare.
You may want to store your sample data as CSV files in your source code control system so that all of your developers can easily load similar data in to each of their development environments.
There are many tools available that you can use to load your sample data in to a new org. The data loader, the Excel Connector, the Import Wizards (under Setup | Data Management), or an integration tool from one of our partners are all good options for replicating data in to an org.
The last step in the development process is to bring everyone’s code and metadata together in a separate integration and packaging org. To do this manually, you will follow the same steps that we walked through in the Replicating Metadata Components Using a Source Code Control System section. If you'd like to automate the metadata integration process, then you'll want to explore the Force.com Migration Tool for Apache Ant.
Some development teams like to automatically integrate and test their code on a regular basis, instead of waiting until the end of a project or development cycle. This practice is referred to as continuous integration. If you'd like to learn how to set up your own continuous integration environment, then the Continuous Integration with Cruise Control article is for you. As a best practice, you should keep your continuous integration org separate from your integration and packaging org.
Packaging and Distribution
The key to distributing a Force.com app is Packaging. A Package is a bundle of Force.com components that you can distribute to your customers over and over. It’s a copy of the metadata that you’ve built. You’ll want to create a managed package because they are the mechanism that gives you control over your application’s intellectual property. Managed packages also allow you to control who has the right to use your application.
Once you’ve created your managed package, you can start distributing it. If your app is aimed at existing Salesforce CRM customers, you will want to list your app on the AppExchange. If you want to distribute your app to customers who don’t have Salesforce CRM, then you’ll want to use Trialforce. Trialforce provides a simple process for provisioning free trials and deploying your Force.com app from your own website. Architecting a Commercial Application has information that will help you decide how to distribute your app.
The diagram below illustrates how existing Salesforce CRM customers can install your package from the AppExchange. It also shows how Trialforce can be used to create brand new trial orgs with your application already embedded inside.
This article discussed the core components of a team commercial application development process on Force.com: Development Environments, the Force.com IDE and a Source Code Control System. It also highlighted how managed packages can be used to distribute your application.
- Development Lifecycle Guide
- An Introduction to Environments
- Architecting a Commercial Application
- Force.com IDE
- Using Force.com with Subversion for Team Development
- An Introduction to Packaging
- Quick Reference for Developing Packages
About the Author
Jesse Lorenz is a Technical Evangelist at salesforce.com, helping independent software vendors, product teams and other partners to architect and build innovative applications on Force.com.