13
Aug

Development Process in Force.com (Salesforce)

Developing applications on the Force.com platform is easy, straightforward, and highly productive. A developer can define application components, such as custom objects and fields, workflow rules, Visualforce pages, and Apex classes and triggers, using the point-and-click tools of the Web interface. Simple changes can be implemented and deployed immediately without affecting other users in the production organization, but When developing complex applications with highly customized logic and user interfaces, configuring on-the-fly in a single environment no longer makes sense. Such applications take a time to develop and require more formal practices to ensure they work as intended and meet users’ needs.

this article prepares you to undertake the development and release of applications on the Force.com platform. Let’s start with one by one development and deploy methodologies

Developing in a Production Organization

You can go with this methodology using the point-and-click tools of the Web interface. You can develop new objects and applications using declarative tools that are powerful and easy to use. In this scenario, all of the development occurs in the production organization, so there is no need for separate development or testing environments. While this process is the fastest way to complete a circuit of the development lifecycle, you are limited in what you can accomplish. For example, you can’t write Apex code directly in a production organization.

Typical development lifecycle:

1. Plan functional requirements.

2. Develop using Salesforce Web tools, using profiles to hide your changes until they’re ready to deploy.

3. Update profiles to reveal your changes to the appropriate users.

4. Notify end users of changes.

Developing with Sandbox

You can go with this methodology when the development tasks that are slightly more complex or that must be isolated from the production organization, In this methodology, you will use separate development organization called “SANDBOX” and all of the development and testing occurs in the development environment, and then the changes are promoted to the production organization. We will deep drive on SANDBOX phase in next section.

Typical development lifecycle:

1. Create a development environment.

2. Develop using Salesforce Web and local tools.

3. Test within the development environment.

4. Replicate production changes in the development environment.

5. Deploy what you’ve developed to your production organization.

Sandbox Orgs (Development environment)

A sandbox is a copy of your production org. Sandboxes contain the same metadata—which is configuration information such as the types of custom objects and fields, applications, and workflows—as your production org. That metadata, as well as data in the case of a full sandbox, is copied to a new org, isolated from your production org. Operations you perform in your sandbox don’t affect your production org.

you can use sandboxes for development, testing, training, or other purposes without compromising the data and applications in your Salesforce production org.

There are different types of sandboxes suitable for different uses.

The following features are disabled and cannot be enabled in sandboxes: 

• Contract expiration warnings

• Case escalation

Contract expiration warnings and case escalation are disabled because they automatically send an email to contacts, customers, and production org users.

• Subscription summary

• Data exports (by clicking Export Now or Schedule Export on the Weekly Export Service page in Setup)

• The ability to create Salesforce sandboxes

• The ability to copy email service addresses that you create in your sandbox to your production org

Sandbox Data Templates

Use sandbox templates with your Partial Copy and Full sandboxes to pick specific objects and data to copy to your sandbox. Sandbox templates enable you to control the size and content of each sandbox.

Isolating Development and Testing

When using a single development environment for development and testing, you must stop development to test, and you can only resume development after you deploy. Unless you have a single developer doing all of these tasks, this can be an inefficient use of resources. A more sophisticated development model allows development to continue while testing and deployment take place. In this case, you need two isolated environments, one for development and one for testing.

The arrangement and flow of the application development process are shown in the following image:

Typical development lifecycle:

1. Create a development environment.

2. Develop using Salesforce Web and local tools.

3. Create a testing environment.

4. Migrate changes from the development environment to testing environment.

5. Test.

6. Replicate production changes in other environments.

7. Deploy what you’ve developed to your production organization.

Developing Multiple Projects with Integration, Testing, and Staging

If you have multiple developers and more than one project in development that will be released at the same time, you need integration testing to make sure that the separate code lines can be merged without conflict. In the future, you might want to include user-acceptance testing (UAT) to determine if the original design requirements are met. A more elaborate development process can also contain a staging environment where you ensure that the deployment to production goes exactly as planned.

The arrangement and flow of the application development process are shown in the following image:

Typical development lifecycle:

1. Create development environments.

2. Develop using Salesforce Web and local tools.

3. Create testing environments, including UAT and integration.

4. Migrate changes from the development environment to integration environment.

5. Test.

6. Migrate changes from integration environment to UAT environment.

7. Perform user-acceptance tests.

8. Migrate changes from UAT environment to a staging environment.

9. Replicate production changes in the staging environment.

10.Schedule the release.

No Comments

Leave a Comment

Your email address will not be published. Required fields are marked *

Contact Us