Application Development on SalesForce

For a project, I was asked to evaluate to see if it can be considered as a platform of choice for a couple of specific applications. During evaluation I mainly looked into

  • the feature set to see how aligned it is when compared to regular enterprise software development routines
  • the development experience to see the efficiency, learning curve, etc.

I have not yet finalized my evaluations, but in this post I will try to outline my first impressions about

First of all is a PaaS (Platform as a service) solution. So what is PaaS? According to Wikipedia, PaaS is the delivery of a computing platform and solution stack as a service. However as stated on the top of the same page, it is not to be trusted and contains a lot of external links and lacks in-line citations. also has a dedicated page just to explain the concept but it also lacks one sentence definition. There are a lot of conflicting definitions here and there on the web. The following is the best one that I could come across on this page.

A service that provides a platform in which to develop software applications, usually web based, with immediate abstractions of the underlying infrastructure.

Two important points to draw attention to, PaaS,

  • Provides a platform to develop application in
  • Abstracts the developed software from the underlying infrastructure

You can also think of PaaS sitting in the middle and filling the void between IaaS and SaaS. Another nice explanation to understand the *aaS stack is provided by Krishna on this Quora entry.

Very simply,

  • In IaaS, you select the pre-canned OS layer, deploy the application stack, deploy your code & then add your data
  • In PaaS, you deploy your code (OS/Application Stack is part of the offering) & then add your data
  • In SaaS, you add your data (everything else part of the offering)

Currently on the market there are different successful PaaS/IaaS solutions like; Google App Engine, Heroku, Amazon Elastic Compute Cloud and is also one of them.

In the traditional sense a PaaS implementation should/might provide the following functionalities.

  • Services to develop, test, deploy, host and maintain
  • An Integrated Development Environment (preferably Web based)
  • Integrated management
  • Multi-tenant architecture with scalability
  • Support for development team collaboration
  • Migration tools for importing/exporting data
  • Multi environment for delivery
  • Integration (with web services, databases, etc)
  • Off-line development (ability to develop, test and deploy while being disconnected from the cloud)

Different PaaS solutions offer different set of functionalities which may or may not correspond to the list given above. An example is, while Google App Engine supports fully off-line development whereas it is not even an issue with You need to be connected in order to develop since the cloud is the only option to deploy and test the functionality being developed.


In order to go into details about the development experience first you have to understand what does development involve? What is code and what is configuration?

Everything is metadata.

Yes, every customization done on is metadata, at least they call it metadata. Even the Apex code implemented is considered to be metatada (simply an extension on the current main app, platform).

The application is, it is a multi-tenant application that can be customized for specific use cases.

  • You can model your data and store it on
  • You can implement Apex code as triggers, controllers, web services, etc.
  • You can integrate external application
  • You can create visual components/pages using VisualForce
  • You can lots of other things

But customization you did on the system is stored as metadata and processed when it is needed. Even the implemented code is not even compiled until it is needed to be run. The scalability is not a concern for your application since all they need to scale is the application itself the


The platform requires at least 75% of your code to be covered by unit tests in order to deploy it to a production organization. Ideally, you should strive for 100% coverage. The code coverage restriction is not enforced for developer sandboxes. Even if you work with projects to make your changes locally with provided tools (like the Eclipse IDE, migration tool), for tests activated by Apex Test Runner, execution occurs on the cloud.


With integrated web IDE, it is possible to develop an application as a team and contribute/share code/configuration with each other and promote implemented functionality to an integration environment and then push it to production. However this kind of development is not so common for classical software development, so I will try explain a better approach which is more controlled/structured that utilizes an SCM (Source Code Management).

First of all, one should know that with the help of Metadata API, it is possible to extract all configuration and customizations done on as resources (which opens new doors for teamwork). Since we can extract all customizations we can also utilize an SCM like GIT, SVN or CVS to version the customizations and even tag them as releases. The use of an SCM system also enables developers to share code/configuration off-line and it can be used as the primary way to share/promote code between developers and environments.

See the following scenario steps for the proposed working model.


  • There is an SCM already set up and ready to be used by the developers.
  • Every developer has the same copy of the migration tool provided by on their local machines.
  • Every developer has his/her own Developer Sandbox or Developer Edition for testing and running the application.

Scenario steps:

  • Harry makes some changes on his sandbox and decides to share his customizations with others
  • Executes ant retrieveCode on his developer box to make migration tool retrieve his customizations from his sandbox (which is on the cloud).
  • Pushes his customizations to version control.
  • Sally needs the changes done by Harry to continue her work, so she pulls the changes from version control.
  • Executes ant deployCode on her developer box to make migration tool deploy the latest customizations to her sandbox and continues to work on her part.
  • And when the work is done, one of them can promote changes to the integration environment or to another environment depending on the environment model in use.

Since there is an SCM involved in the process, developers might use merge tools and other tools to resolve conflicts, tag releases, etc. See the following figure to understand the pieces involved in the process.

Version Control

There is no built-in version control provided by the platform itself, it is suggested by to use an external version control system. See “Working as a Team” section to see how to apply the concept. Since all the customizations done on a application is available through the Metadata API, any version control system can be easily integrated into the development process. There are different ways to extract customizations from a application;

  • Eclipse plugin
  • Migration Tool
  • Or any tool that works with Metadata API

Eventually all the tolls depends on the Metadata API and it is the primary way to push/retrieve code/configuration to/from

Continuous Integration

It is possible to build/deploy the application to an organization, run the tests via this organization and collect the results. The following figure illustrates a possible setup to realize continuous integration for a application.

The proposed setup is using CruiseControl as the CI tool and ant as the build tool. It is possible to replace CruiseControl with any other CI tool easily, since the actual build is done via ant using the ant extension library ant-salesforce.jar provided by And most of the CI tools can trigger ant builds out-of-the-box.

See this page for more information on the subject.

Multiple Environments

Since does not support fully off-line development, also provides multiple-environment support to be able to manage different development processes. These environments are called sandbox or organization in vocabulary. Depending on the project’s complexity it is possible to use different sandbox models from simple to complicated;

  • simple being just a production organization
  • and complex being multiple sandboxes for a classical enterprise application release cycle utilizing multiple developer sandboxes, integration sandbox, QA sandbox, UAT sandbox, staging sandbox, production sandbox, etc.

The decision to use which sandbox model depends on two major factors;

  • The nature of the feature that will be developed; standalone or major improvement on an existing production application.
  • The number of teams/developers that will be involved in the project.

The other feature brought by is “Code Path Enforcement”. You may configure, from where an organization may receive changes. In the complex scenario given below; Production organization only receives changes from “Staging organization”, so there is no way to send changes which is not tested on Staging organization.

Following figures for the simplest and the most complex scenarios.



Multiple Developer Sandboxes

Not all the environments have the same requirements regarding the resources and data, that is why provides different types of sandboxes to use with different environments. See the following list for the types of sandboxes and the purposes.

  • Developer Edition: Free option for developing on platform. Cannot access the production system.
  • Partner Developer Edition: This is a special edition to develop multi-organization products on
  • Full-copy Sandbox: Full sandboxes copy your entire production organization and all of its data, including standard and custom object records,documents, and attachments.
  • Configuration Only Sandbox: Configuration-only sandboxes copy all of your production organization’s reports, dashboards, price books, products,apps, and customizations, but exclude all of your organization’s standard and custom objectrecords, documents, and attachments.
  • Developer Sandbox: As the name implies, Developer Sandboxes are special configuration-only sandboxes intended for coding and testing by a single developer.


It is a very different development experience, you are very limited by the platform itself and it feels like you are not coding but it is the idea. You have a very robust multi-tenant application and you can tailor it for your needs. Overall I really like the idea behind but like every framework/platform, before jumping right into it you have to consider if it is the best platform to develop a certain application.

IMHO, is mostly suitable for the data centric applications because the platform is centered around a very flexible database and it allows you to easily develop applications which are data-centric, e.g., CRM, back-office applications.

If you need an application that need the followings, you can implement it with a point-and-click-development approach.

  • Database
  • Workflow & Approval
  • Reports and Dashboards around shared data

If we move beyond point-and-click development approach, with the Web Service and Mashup support, with Visual Force to create enhanced views and by using ready components on AppExchange, you can write any kind of applications on the platform.

The thing is, you can not write a framework with this platform 🙂

Leave a Reply

Your email address will not be published.