The key for turning an idea into reality lies in its execution. From having the inception of an idea to getting it implemented as an application and into the hands of users is an exciting journey, and one that constantly develops and evolves between you and your users. One of the great things about developing on Force.com is the support you get from the platform beyond the core engineering phase of the production process.
In this first chapter, we will use the declarative aspects of the platform to quickly build an initial version of an application that we will use throughout this book, which will give you an opportunity to get some hands-on experience with some of the packaging and installation features that are needed to release applications to subscribers. We will also take a look at the facilities available to publish your application through Salesforce AppExchange (equivalent to the Apple's App Store) and finally provide end user support.
We will then use this application as a basis for incrementally releasing new versions of the application throughout the chapters of this book, building on our understanding of enterprise application development. The following topics outline what we will achieve in this chapter:
- Required organizations
- Introducing the book's sample application
- Package types and benefits
- Creating your first managed package
- Package dependencies and uploading
- Introduction to AppExchange and creating listings
- Installing and testing your package
- Becoming a Salesforce partner and its benefits
- Licensing
- Supporting your application
- Customer metrics
- Trialforce and Test Drive
Several Salesforce organizations are required to develop, package, and test your application. You can sign up for these organizations at https://developer.salesforce.com/. Though in due course, as your relationship with Salesforce becomes more formal, you will have the option of accessing their Partner Portal website to create organizations of different types and capabilities. We will discuss this in more detail later.
It's a good idea to have some kind of naming convention to keep track of the different organizations and logins. Use the following table as a guide and create the following organizations via https://developer.salesforce.com/. As stated earlier, these organizations will be used only for the purposes of learning and exploring throughout this book:
|
Username |
Usage |
Purpose |
|---|---|---|
|
Packaging |
Though we will perform initial work in this org, it will eventually be reserved solely for assembling and uploading a release. | |
|
Testing |
In this org, we will install the application and test upgrades. You may want to create several of these in practice, via the Partner Portal website described later in this chapter. | |
|
Developing |
In a later chapter, we will shift development of the application into this org, leaving the packaging org to focus only on packaging. |
Note
You will have to substitute myapp and my.com (perhaps by reusing your company domain name to avoid naming conflicts) with your own values. You should take the time to familiarize yourself with [email protected].
The following are other organization types that you will eventually need in order to manage the publication and licensing of your application. However, they are not needed to complete the chapters in this book:
Typically, the LMO and APO can be the same as your primary Salesforce production org, which allows you to track all your leads and future opportunities in the same place. This leads to the rule of APO = LMO = production org. Though neither of them should be your actual developer or test orgs, you can work with Salesforce support and your Salesforce account manager to plan and assign these orgs.