1. Development Lifecycle Guide (part 1)

2. ABDELHAKIM
MOUTTAQUI
Chef de projets Sénior, SIWAY
@adbelhakim
@casasfdug
@SiWay_WebAgency
https://ma.linkedin.com/in/abdelhakimmouttaqui
https://www.linkedin.com/company/siway
http://abdelhakimmouttaqui.blogspot.com/
abdelhakim.mouttaqui@siway.fr
contact@siway.fr

3. SIWAY - VOTRE INTÉGRATEUR CERTIFIE SALESFORCE
DEVELOPMENT LIFECYCLE GUIDE (PART 1)
Sommaire :
1. Introduction to the Force.com Development Lifecycle
2. Development Environments
3. Development Tools

4. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
1. INTRODUCTION TO THE FORCE.COM DEVELOPMENT LIFECYCLE
Developing 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.

5. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
1. INTRODUCTION TO THE FORCE.COM DEVELOPMENT LIFECYCLE
Developing with Sandbox
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.
Typical development projects:
•New custom objects, tabs, and
applications
•Integrations with other systems
•Apps involving Apex, Visualforce,
workflow, or new validation rules

6. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
1. INTRODUCTION TO THE FORCE.COM DEVELOPMENT LIFECYCLE
About Sandbox Organizations
A sandbox is a copy of your production organization. Sandboxes contain the same metadata as your
production organization. That metadata, as well as data in the case of a full sandbox, is copied to a
new organization, isolated from your production organization. Operations you perform in your sandbox
don’t affect your production organization.
Sandboxes are available in :
• Enterprise
• Unlimited
• and Performance Editions.
With Unlimited and Performance Edition, you can create multiple sandbox copies of different types.
Each sandbox instance is isolated from every other sandbox instance, just as they are from production.

7. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
1. INTRODUCTION TO THE FORCE.COM DEVELOPMENT LIFECYCLE
About Migrating Changes between Organizations
A deployment connection alone doesn't enable change sets to be sent between organizations. Each
organization must be authorized to send and receive change sets. This added level of security
enforces code promotion paths and keeps organizations' setup metadata from being overwritten by
mistake.

8. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
1. INTRODUCTION TO THE FORCE.COM DEVELOPMENT LIFECYCLE
DEMO

9. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
2. DEVELOPMENT ENVIRONMENTS
Developing on the Force.com platform requires a development environment, a place where you can
work without affecting other users.
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. 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.
Isolating Development and Testing
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 development
environment to testing environment.
5. Test.
6. Replicate production changes in other
environments.
7. Deploy what you’ve developed to your
production organization.
Typical development projects:
•New custom objects, tabs, and applications
•Integrations with other systems
•Apps involving workflow or new validation
rules

10. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
2. DEVELOPMENT ENVIRONMENTS
Developing Multiple Projects with Integration, Testing, and Staging
UAT : user-acceptance testing
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 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
staging environment.
9. Replicate production changes in staging
environment.
10.Schedule the release
Typical development projects:
• Concurrent development of new applications in multiple
environments
• Projects that require team development

11. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
2. DEVELOPMENT ENVIRONMENTS
About Types of Development Environments
There are two types of development environments: sandbox organizations and Developer Edition
organizations
Sandbox type Description
Developer
Developer sandboxes copy customization (metadata), but don't copy production data,
into a separate environment for coding and testing.
Developer Pro
Developer Pro sandboxes copy customization (metadata), but don't copy production
data, into a separate environment for coding and testing. Developer Pro has more
storage than a Developer sandbox. It includes a number of Developer sandboxes,
depending on the edition of your production organization.
Partial Copy
A Partial Copy sandbox is a Developer sandbox plus the data that you define in a
sandbox template.
Full
Full sandboxes copy your entire production organization and all its data, including
standard and custom object records, documents, and attachments. Use the sandbox
to code and test changes, and to train your team about the changes. You can refresh
a Full sandbox every 29 days.

12. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
2. DEVELOPMENT ENVIRONMENTS
Sandbox Uses
Use Type of SandBox Note
Development Developer or Developer Pro sandbox Full sandboxes are more costly in
terms of create and refresh time, and
would also give developers access to
data that might not be appropriate
Testing •Unit tests and Apex tests: Developer or Developer
Pro sandbox
•Feature tests and regression tests: Partial Copy
sandbox (with a standard data set loaded)
Testing external
integrations
Full sandbox is best when an external system
expects full production data to be present.
Partial Copy sandboxes may be
appropriate in special cases when you
want to use sample data or a subset
of your actual data. Works well if
you’re using external IDs
Staging and user-
acceptance testing
Full sandbox is best for validation of new
applications against production configuration and
data.
Partial Copy sandboxes are
appropriate if testing against a subset
of production data is acceptable, for
example, for regional tests.
Production
debugging
Full sandbox

13. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
2. DEVELOPMENT ENVIRONMENTS
Sandbox Considerations and Limitations
Sandbox functionality is not identical to production, and you will need to plan for the differences as well as for the copy
process itself.
Consider the following when creating or refreshing a sandbox:
• Creating or refreshing a sandbox copy is a long-running operation that might complete in minutes, days, or even
more than a week.
• Refreshing a sandbox deletes and recreates the sandbox as a new copy of the production organization.
• Setup and data changes to your production organization during the sandbox creation and refresh operations might
result in inconsistencies in your sandbox. Therefore, it’s best to freeze or minimize changes to your production
organization while creating or refreshing a sandbox.
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
email to contacts, customers, and production organization 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 organization
• The ability to publish Site.com sites

14. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
2. DEVELOPMENT ENVIRONMENTS
Updating Environmental Dependencies
Once you create a sandbox, configure it to update environmental dependencies and merge project contents before
beginning development.
Environmental
Dependency
Details
Login privileges If your developers and testers do not have logins on production, or do not have the necessary privileges, you need to give them the necessary
access in the development environment.
Email addresses When you create a sandbox, email addresses are automatically changed so that email alerts and other automatic notifications are not sent from
the sandbox during development. When your developers and testers log into the sandbox, they must change their email address back to a real
address to receive email messages sent from the sandbox.
Email recipients If you want to test outbound email for features such as escalations or dashboards, you must update the list of recipients, because these lists are
removed when the sandbox is created to prevent unnecessary emails.
External URLs If your production organization is integrated with external systems, you will probably not want your sandbox copy to communicate with the
production versions of those external systems, so as not to mix production and non-production data. For example, if you use outbound messaging
or web service callouts, you will want to update the URLs called by those services to point to your external development environment(s) for those
applications. Likewise, since sandboxes run on a different instance than the production organization, to test integrations with sandbox you will
need to change the API endpoint hostname from login.salesforce.com to test.salesforce.com
Hard-coded URLs In general, when linking from one Force.com page to another, the links should be relative (omitting the hostname) rather than absolute, and
dynamic (looking up the ID, record, or page by name) rather than static. This allows you to migrate the URLs between different organizations,
which might have different hostnames or record IDs. If your application contains hard-coded URLs from one Force.com page to another, they
might break when they are clicked from the sandbox or, worse, take a user who thinks he is in a development environment back to the production
organization.
Hard-coded IDs Some components are commonly accessed via their ID, such as RecordTypes. When you create a sandbox copy, code that uses these IDs to
reference these components continues to work because production IDs are retained by the sandbox copy. However, the reverse is not true—
migrating from sandbox to production (or between any two organizations) via metadata maintains components' names, but if the component does
not exist in the target organization, a new ID will be generated. Therefore, migrating code that contains a hard-coded ID can cause the code to
break. As a best practice, wherever possible, you should obtain a component's ID by querying for it by name.
Existing projects If you have existing development projects, you need to merge that work into the new development environment.

15. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
2. DEVELOPMENT ENVIRONMENTS
Creating User Templates
A developer user template is an abstract user that has permissions required to develop on the sandbox (for example, the
“Modify All Data” permission), but is not active on your production organization. After you create or refresh a sandbox,
you activate the developer user in the sandbox and assign it to the individual who will be developing there.
To create a developer template:
1. Create a new user on your production organization.
2. Edit the user to give it the necessary permissions.
3. Deactivate the user on the production organization.
4. Create or refresh a sandbox.
5. Activate the user on the sandbox.
6. Optionally change the email address, password, or other environmental settings
Your sandbox has the same number of licenses as production, but it is unlikely that all of your users will log into it. When
you create or refresh a sandbox, the same users who are active in production are active in the sandbox, so if all
licenses are occupied you will need to deactivate an active user to activate the inactive developer user. Just make
sure that the user you're deactivating in sandbox is one of the many production users who will never log into that
environment. Likewise, you should make your production developer user template inactive on the production
organization, so it doesn't consume a paid production license

16. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
2. DEVELOPMENT ENVIRONMENTS
Managing Sandboxes
To manage a sandbox, from Setup enter Sandboxes in the Quick Find box, then select Sandboxes. A list of your existing
sandboxes displays.
• Click New Sandbox to create a new sandbox. Salesforce deactivates the New Sandbox button when an organization
reaches its sandbox limit. If necessary, contact Salesforce to order more sandboxes for your organization.
• Click Sandbox History to see a log of your sandbox refresh history, including when sandboxes were created and who
created them.
• Click Refresh to replace an existing sandbox with a new copy. Salesforce only displays the Refresh link for sandboxes that
are eligible for refreshing, which varies for different types of sandboxes. Your existing copy of this sandbox remains available
while you wait for the refresh to complete. The refreshed copy is inactive until you activate it.
• Click Activate to activate a refreshed sandbox. You must activate your refreshed sandbox before you can access it.
Salesforce only displays this option for sandboxes that are not activated.
• Click Del to delete a sandbox. The delete option is only available if your organization exceeds its sandbox limit.
• Administrators can click Login to log into a sandbox as a user. Salesforce only displays this option for active sandboxes.
Users can log in to the sandbox at https://test.salesforce.com by appending .sandbox_name to their Salesforce usernames.
For example, if a username for a production organization is user1@acme.com, and the sandbox is named “test,” the
modified username to log in to the sandbox is user1@acme.com.test.
• Click on a sandbox name to view details about the sandbox, including the sandbox type and when it was created

17. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
3. DEVELOPMENT TOOLS
Regardless of your role in the development process, it is important to understand at a high level how all of the
Force.com development tools operate, and the development tasks that overlap each other.
The Force.com IDE is the best tool for team development, migration of selected components, and writing Apex.
The Force.com Migration Tool, on the other hand, is useful for migrating large scale or repetitive changes between
environments.
These and other Force.com tools are examined in the following sections

18. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
3. DEVELOPMENT TOOLS
Force.com App Builder Tools
The Salesforce user interface makes application development easy with point-and-click app builder tools. From Setup,
you can modify the metadata of your organization

19. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
3. DEVELOPMENT TOOLS
Force.com IDE
The Force.com IDE is an integrated development environment for developing applications on the Force.com
platform using Apex, Visualforce, and metadata components
Metadata API can deploy and retrieve up to 10,000 files or 400 MB at one time. If you need to retrieve or
deploy more than either of these limits, you must do so in batches.

20. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
3. DEVELOPMENT TOOLS
About Metadata API
Metadata API provides two parts that work in conjunction: a rich and powerful metadata model and an application
programming interface (API). The metadata model describes the components in your organization.
For example, Salesforce custom objects and their fields can be controlled by manipulating the XML files provided by
Metadata API.
Metadata API also includes a set of Web service methods that provide programmatic access to the configuration and
source of your metadata components.
In other words, it describes what you can do with those components, such as create an object or deploy one. If it helps
you to separate them into two parts, you can think of the metadata components as nouns, and the API calls as verbs.
With Metadata API you can:
• Work with setup configuration as metadata files.
• Copy, paste, merge, and manipulate metadata files using familiar tools, such as text editors, IDEs, batch
scripts, and source control systems.
• Migrate configuration changes between organizations, either between two development environments or from
development to production.
• Create your own tools for managing organization and application metadata

21. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
3. DEVELOPMENT TOOLS
Force.com Migration Tool
The Force.com Migration Tool is a Java/Ant-based command-line utility for moving metadata between a local
directory and a Salesforce organization. The Force.com Migration Tool allows you to migrate metadata between
unrelated organizations, so in that sense it’s more powerful than change sets.
Unlike the Force.com IDE, the Force.com Migration Tool has no graphical user interface. You choose the
components you want to deploy, the server address, and other deployment details by editing control files in a text
editor and using command-line arguments.
Most people will find the graphical user interface of the Force.com IDE easier to use than editing text files and
providing arguments on the command line.
However, the Force.com Migration Tool is especially useful in the following scenarios:
• Development projects where you need to populate a test environment with large amounts of setup
changes—making changes with an automated script is far faster than entering them by hand.
• Deployments where you need to change the contents of files between organizations—for example, if you
want to change the Running User on a dashboard, you can retrieve the Running User from organization A,
make a change, and then deploy the Running User to organization B. If you tried to do this in the
Force.com IDE, the IDE would force you to save the change back to organization A (where the organization
B user probably does not exist) before launching the Deploy Wizard to deploy to organization B. The
Force.com Migration Tool gives you complete control over the retrieve() and deploy() commands; editing
and saving a file on your local file system does not change the metadata in any organization until you
choose to deploy it.
• Multi-stage release processes—a typical development process requires iterative building, testing, and
staging before releasing to a production environment. Scripted retrieval and deployment of components
can make this process much more efficient.
• Repetitive deployment using the same parameters—you can retrieve metadata from your organization,
make changes, and deploy your changes to an organization. If you need to repeat this process, it is as
simple as calling the same deployment target again.
• When migration from staging to production is done by highly technical resources—anyone who prefers
deploying in a scripting environment will find the Force.com Migration Tool a familiar process.

22. DEVELOPMENT LIFECYCLE GUIDE (PART 1)
3. DEVELOPMENT TOOLS
Data Loader
Data Loader is a client application for the bulk import or export of data. Use it to insert, update, delete, or export
Salesforce records.
Use Web-based importing when:
• You are loading less than 50,000 records.
• The object you need to import is supported by
import wizards. To see what import wizards are
available and thus what objects they support, from
Setup, enter Data Management in the Quick Find
box, then select Data Management.
• You want to prevent duplicates by uploading
records according to account name and site,
contact email address, or lead email address.
Use Data Loader when:
• You need to load 50,000 to 5,000,000 records.
Data Loader is supported for loads of up to 5
million records. If you need to load more than 5
million records, we recommend you work with a
Salesforce partner or visit the App Exchange for a
suitable partner product.
• You need to load into an object that is not yet
supported by the import wizards.
• You want to schedule regular data loads, such
as nightly imports.
• You want to export your data for backup
purposes.

23. Q & A

24. Merci !

25. CONTACT
www.siway.fr
Tel Maroc : 05 22 26 99 97
contact@siway.fr