If you are a consultant or developer working with multiple clients, there are a number of Force.com technologies that allow for reuse of your commonly needed assets. Many of these have already been covered separately as wiki articles or blog posts on this site. The purpose of this post is to pull a few topics together and demonstrate strategies that will make you and your project teams more productive.
Eliminating administrative overhead and leveraging reuse whenever possible will provide additional opportunities to deliver high value, innovative services and applications to customers. Also, you’ll generate valuable resources for quickly preparing demos, training employees or customers, and drive more efficient collaboration throughout your practice.
The topics I’ll highlight in this post include:
- Migrating Configuration between Environments
- Custom Applications as a Configuration Library
- Establishing a Code Repository
Migrating Configuration between Environments
Environment (or organization / ‘org’) configuration can be one of the most time consuming activities during the implementation phase of any professional services or custom application development project. Leveraging an automated migration strategy is key to eliminating repetitive manual tasks and can help avoid configuration errors.
There are two primary technologies available for migrating configuration between environments. The first is packaging.
Packaging
“Packages are like suitcases that can contain your components, code, or apps. You can use a package to bundle something as small as an individual component or as large as a set of related apps.”
Packages are distributed via the AppExchange and can be publicly listed on the directory, or privately listed and distributed directly to a client or amongst an internal team. These Packages can also be ‘managed’ or ‘unmanaged’. From the article An Introduction to Packaging:
“Packages come in two forms: unmanaged and managed. Unmanaged packages can be used for a one-time distribution, like a template. These are ideal for sharing application templates or code samples. The installer receives an independent copy of the components. Managed packages provide intellectual property protection (the source code of many components is not available, in contrast to unmanaged packages), as well as a way for the package creator to offer upgrades to the package. Managed packages are a great way of releasing applications for sale, and also provide support for license enforcement features.”
The following screencast demonstrates how to create and distribute an application template using an unmanaged package (in less than 5 minutes!):
There are some considerations regarding which components in your application are package-able, their attributes, their behavior, as well as the impact on the org limits for the different salesforce editions. Please refer to the Packaging Guide for these details.
UPDATE: Another consideration is that unmanaged packages can only be used if none of the components being migrated exist in the destination org. This can particularly cause problems on a sandbox to production migration. The best tool to use for this scenario is the Force.com IDE, which is described and demonstrated below.
Metadata API
“On The Force.com platform, metadata defines a rich set of components including all aspects of Force.com functionality, from the appearance of user interfaces through workflow. Examples of components of metadata include custom user interfaces created using Visualforce, generated page layouts, and even Apex classes for custom application functionality. In short, just about every aspect of an application developed on the Force.com platform, ranging from workflows to the configuration of database objects (that store data!) are metadata.”
This customization information can be managed and migrated between environments using the Metadata API. Jon’s Introduction to Metadata and Development as a Service provides an excellent overview of how to do this using the Force.com IDE, and the Force.com Migration Tool, and describes a typical development migration path:
“The Developer Edition (DE) environment provides a home for your applications and data as you develop your functionality. This environment is referred to as an organization or org. You could begin creating an application by logging into this org using a web browser, accessing the Setup menu and creating your database objects.
You can have many such orgs. If you have deployed your application within your company, you probably did so in a production org, which may have license and data volume restrictions depending on your current salesforce.com subscription. Or you could be testing in a sandbox org, which mirrors some of the data found in your production org, but is separate from the production org and its operation.
… As with other platforms, moving an application system from one org to another will probably involve moving both the source of the application, metadata on the Force.com platform, as well as the underlying data. Used in conjunction, the metadata API and web services API provide this functionality.”
As a consulting or development firm, using the metadata API you can expand upon this concept and redeploy a base application configuration or template out from a source development org to multiple targets including prospect trials, demonstration environments, team development environments, or a customer sandbox or production org. In many cases, this would be your starting point for further configuration, customization, development, and testing based on your clients’ unique business requirements.
In the following screencast, I demonstrate migrating a custom app between Orgs using the metadata API and Force.com IDE (also under 5 minutes):
If you are a member of the salesforce.com partner program as a consulting partner or ISV, you have access to our partner portal.
The ‘Create Demo/Test Org’ tab in the portal allows you to self provision enhanced Developer, Platform, Enterprise, and Professional Edition environments to build, test, and demo your custom apps or reusable templates. Then, using the techniques detailed above, you’ll be able to migrate these between environments and client orgs.
Custom Applications as a Configuration Library
Now that you are familiar with some techniques for migrating configurations between salesforce.com orgs, one method for building out a configuration library of reusable assets and code is to leverage Custom Apps.
The key to this technique is to logically group your data model, configuration templates, assets, code, etc. This could be by demo type, target audience, industry vertical, or (obviously) by application. Grouping your reusable assets as Custom Apps makes deployment to (and further customization in) another org simple and easy to manage.
An Unlimited Edition Sandbox would be ideal for building out such a library as there is no limit to the number of Custom Apps that you can create or load. However, you can also use a free Developer Edition Org to build a library of up to 10 Apps. For a full list of Salesforce Editions and Limits that you need to take into consideration, please refer to online help.
Establishing a Code Repository
Setting up a repository using Subversion, Google Code, or a similar technology is key for collaboration and code reuse amongst your developers on customer engagements. Using the standard synchronization features of the Force.com IDE, you can create a project that enables multiple developers to develop against a shared source code repository:
“As the Force.com IDE is built on the Eclipse Platform, you can also use standard Eclipse features such as version control support. A version control system allows you to track changes to a set of files over time. Using Eclipse’s version control features in tandem with the Force.com IDE allows you to store your Force.com applications in source control, compare current and historical versions of a component, roll back changes, and work collaboratively by sharing a single application definition across a development team. Eclipse can connect to the popular, open source Subversion system using a plug-in called Subclipse. Once installed, you will be able to retrieve source code from a Subversion source code repository, including Code Share projects created by the Force.com developer community.”
This Code Share article demonstrates how to check out and share a project using the Force.com IDE and Google Code.
Using all, or any combination of these techniques will enable your development and implementation teams to collaborate more efficiently. They’ll be able to quickly redeploy and reuse work, and more easily demo innovative products and services to potential clients.