[Link]

com/ch/361604092/salesforce-development-lifecycle-deployment-designer-
flash-cards/
[Link]
[Link]
designer

There are three Development Models:

 Change set development

 Org development
 Package development

Customizations that don’t affect data are safe to create in a production org, such as
developing new dashboards, reports, and email templates.

Step 1: Plan Release

Start your customization or development project with a plan. Gather requirements and
analyze them. Have your product manager (or equivalent) create design specifications and
share them with the development team for implementation. Determine the various
development and testing environments the team needs as the project progresses through the
ALM cycle.

Step 2: Develop
Complete the work, following the design specifications. Perform the work in an environment
containing a copy of the production org’s metadata, but with no production data. Develop on
Lightning Platform using an appropriate combination of declarative tools (Process Builder,
the Custom Object wizard, and others in the UI) and programmatic tools (Developer Console,
Source Code Editor, or Visual Studio Code).

Step 3: Test
Exercise the changes you’re making to check that they work as intended before you integrate
them with other people’s work. Do your testing in the same type of environment as you used
in the develop step, but keep your development and integrated testing environments separate.
At this point, focus on testing your changes themselves, not on understanding how your
changes affect other parts of the release or the app as a whole.

Step 4: Build Release

Aggregate all the assets you created or modified during the develop stage into a single release
artifact: a logical bundle of customizations that you deploy to production. From this point on,
focus on what you’re going to release, not on the contributions of individuals.

Step 5: Test Release

Test what you’re actually going to deploy, but test safely in a staging environment that
mimics production as much as possible. Use a realistic amount of representative production
data. Connect your test environments with all the external systems they need to mimic your
production system’s integration points. Run full regression and final performance tests in this
step. Test the release with a small set of experienced people who provide feedback (a
technique called user-acceptance testing).

Step 6: Release
When you’ve completed your testing and met your quality benchmarks, you can deploy the
customization to production. Train your employees and partners so they understand the
changes. If a release has significant user impact, create a separate environment with realistic
data for training users.

Releases typically fall into one of three categories.

Patch
Bug fixes and simple changes. Simple changes include reports, dashboards, list views, and
email templates.
Minor
Changes with limited impact, such as a new workflow rule or trigger impacting a single
business process. These releases typically require testing, but only limited training and
change management. Typically, a team delivers the changes for a minor release within a few
weeks.
Major
Changes with significant impact, including changes with one or more dependencies. Because
these releases can greatly affect the user experience and data quality, they require thorough
testing, training, and careful change management. Major releases are typically delivered once
a quarter (Salesforce does it three times a year).

Sandbox Types
Developer Sandbox
A Developer sandbox is intended for development and testing in an isolated environment. A
Developer Sandbox includes a copy of your production org’s configuration (metadata).

Developer Pro Sandbox

A Developer Pro sandbox is intended for development and testing in an isolated environment
and can host larger data sets than a Developer sandbox. A Developer Pro sandbox includes a
copy of your production org’s configuration (metadata). Use a Developer Pro sandbox to
handle more development and quality assurance tasks and for integration testing or user
training.

Partial Copy Sandbox

A Partial Copy sandbox is intended to be used as a testing environment. This environment
includes a copy of your production org’s configuration (metadata) and a sample of your
production org’s data as defined by a sandbox template. Use a Partial Copy sandbox for
quality assurance tasks such as user acceptance testing, integration testing, and training.

Full Sandbox
A Full sandbox is intended to be used as a testing environment. Only Full sandboxes support
performance testing, load testing, and staging. Full sandboxes are a replica of your production
org, including all data, such as object records and attachments, and metadata. The length of
the refresh interval makes it difficult to use Full sandboxes for development.
We recommend that you apply a sandbox template so that your sandbox contains only the
records that you need for testing or other tasks.
When you create a Full sandbox, you also have to decide how much field tracking history and
Chatter activity to include.
* The default is to omit field tracking, but you can include up to 180 days of field tracking. If
you track field history for many objects in your production org, specify fewer days to avoid
generating an excessive amount of data.
* Chatter activity data can be extensive, which can add a significant amount of time to your
Full sandbox copy.
Limit the amount of field history that you copy, and copy your Chatter data only if you need
it for your testing use cases.
SANDBOX TYPE PROFESSIONAL EDITION PERFORMANCE EDITION UNLIMITED EDITION ENTERPRISE EDITI
Developer Sandbox 10 100 100 25
Developer Pro Sandbox 5 5
Partial Copy Sandbox 1 1 1
Full Sandbox 1 1

SANDBOX TYPE REFRESH INTERVAL STORAGE LIMIT WHAT’S COPIED SANDBOX TEMPLAT
Data storage: 200 MB
Developer Sandbox 1 day File storage: 200 MB Metadata only Not available
Data storage: 1 GB
Developer Pro Sandbox 1 day File storage: 1 GB Metadata only Not available
Data storage: 5 GB
Partial Copy Sandbox 5 days File storage: 5 GB Metadata and sample data Required
 Available
Full Sandbox 29 days Same as your production org Metadata and all data
Partial Copy Sandbox is limited to maximum 10000 records per object. Even though, the
sandbox-storage is 5 GB, the 10000 limit is applied.
Salesforce Custom Object record needs 2 KB space to store its data.

What is a Salesforce Center of Excellence. A Salesforce COE acts as a central governing

body for the entire organization. It brings together stakeholders from across the organization
to create a single, well-defined group that is responsible for making decisions when it comes
to Salesforce.

When to Choose Waterfall

Simple work:
* The work is simple and predictable.
* Anyone can determine how to complete the work.
Complicated work:
* The work is predictable, but requires expertise.
* The work can be automated.

 Complex processes that will need to be built are thoroughly understood and
documented before coding begins.
 Milestones, timelines and estimates tend to be more accurate and predictable due to
the upfront due diligence.

When to Choose Agile

Complex work:
* The work is based on consistent feedback, risk, and innovation.
* You want to try something, see how it works, and change course according to new
learnings.
* You’re making new products, software, and services, and you’re doing things that have
never been done before.

When trying to choose a workflow process, ask yourself these questions.

* How much do we know about the project at hand?
* How clear are the project’s objectives and requirements?
* How clear and well-defined is the solution?
* What is the team’s and stakeholder’s experience with these methodologies?
* How complex is the work?

Key Stakeholders
All projects have a large number of people involved, and these can normally be found in the
following groups.
Information Technology
The people who administer and develop your Salesforce instances are key to your governance
framework. Whether you call your technology team IT, IS, or just that person in the corner
cube with a lot of monitors, these people are important participants. After all, they’re the ones
who deliver the great functionality you deploy.
Business Units
In the past, the technology teams view their relationship with business divisions through the
lens of a customer. The business needs something. Analysts gather requirements, and then the
technology team builds it based on those requirements and delivers it to their customers. That
kind of relationship isn’t collaborative enough in today’s world. Things change too fast. A
lean governance framework establishes a continuous partnership between technology teams
and the people who run the rest of the business. We address this more later, but for now keep
in mind that this ongoing partnership is one of the most important aspects of a modern lean
governance model.

End Users
In addition to leaders in these two divisions of your company, end users play important roles,
too. After all, they are the ones in the trenches using Salesforce every day to get their work
done. Who else has more knowledge about the business process you’re trying to optimize in
Salesforce? Salesforce Success Cloud experts always try to involve end users during their
engagements, especially during discovery sessions. More often than not, end users generate
valuable feedback that surprises business unit leaders and project teams. Keep end users in
mind for your governance framework—it’s well worth the effort.

Roles and Responsibilities

We’ve established that governance is all about building a deep partnership between business
and technology teams, but who owns what in this partner dance?
People on the Business Unit side of things have to own the project vision and strategy.
Remember Ursa Major Solar from the previous unit? To increase profitability, it must sell
more turnkey systems. To accomplish this, Ursa Major needs a mobile-friendly way for its
users to generate sales quotes for these products. This vision is created and owned by the
Sales division. The Sales division is also responsible for gathering and prioritizing the
requirements for the new quoting system. For the quoting system, what’s more important—
digital signature functionality or a discount approval workflow? If the budget won’t allow for
both features, which one should be delayed or canceled? The Sales department makes the
call. In addition to these two major responsibilities, the business teams are also responsible
for things such as:
* Gathering end-user feedback
* Onboarding users
* Owning and managing the budget
* Designating a product owner

Note: Product Owner is a term from Agile development technologies. We won’t cover this in
detail in this module, but we’ll instead refer you to a different Trailhead module that
introduces Agile development processes.
While this might seem like the lion’s share of the responsibilities, the technology team owns
a huge chunk of responsibility, too. This is the group that actually builds and maintains the
system. The Salesforce technology team is also responsible for providing accurate estimates
of effort for the functionality the business needs. Here are a few other key aspects in a lean
governance framework that the Salesforce technology team needs to own.
* Defining the release schedule
* System testing
* System support
What does this lightweight and agile framework look like? It includes five key processes.
(Lean Governance Framework)
* Vision and strategy
* Business backlog
* Software development lifecycle
* Data strategy, architecture, and management
* Communication strategy

Operating Model and Core Committees

With those five core processes defined, we can now move into the actual structure of the
Salesforce lean governance framework. The first thing to figure out is your operating model.
The three basic options are:
* Centralized: A single governance framework with a one set of processes and normally
focused on a single solution, single business unit, or global processes. Generally the best
option for smaller, single-org companies.
* Decentralized: Federated governance framework with independent governance
frameworks and the possibility of different sets of processes for different business units. The
decentralized model is used for organizations that have multiple Salesforce environments
with highly autonomous business units or geographies.
* Hybrid: Common governance framework with each business unit having its own
autonomy. This approach is effective for larger companies that want to standardize their best
practices and processes under a common framework, yet allow some amount of autonomy for
their different divisions or geographies.

* Executive Steering Committee: This group owns the overall vision and strategy, sets the
priorities and oversees the overall project budget. It also acts as the final escalation point for
disagreements that the project teams are unable to resolve. Membership should include key
executive leaders across the impacted business units, IT, and the project management team.
The committee should meet at least quarterly or more often, depending on the release
cadence. Here’s a typical agenda for the steering committee.
* Update on actions from the last meeting.
* Review of the project(s) overall health and KPIs.
* Review and update the vision and strategy if required.
* Review of the overall project(s) budgets.
* Review of project risk register.
* Discuss any other competent business.

* Project Management Committee: This group manages the day-to-day details of all major
projects. This team should meet once per week with representatives from all key stakeholders
in attendance. Suggested agenda:
* Update on actions from the last meeting.
* Review of the project(s) overall health and KPIs.
* Project resources and team skill requirements.
* Review of project risk register.
* Discuss any other competent business.

Requirement Traceability Matrix (RTM) is a table (mostly a spreadsheet) that shows if

each requirement has a respective Test case/cases to make sure if the requirement is covered
for testing.
It is basically used to ensure that ALL the requirements and Change Requests are or will be
tested.

A business continuity plan (BCP) is a document that outlines how a business will continue
operating during an unplanned disruption in service

1. Understand the roles and responsibilities of the following teams. For example, whom to
contact when you receive a requirement during middle of a project, that is not feasible to
deliver by the promised deadline?
1. Center of Excellence (CoE):- Most IT firms have CoE today. CoE is a team of people
that promotes collaboration and uses best practices around a specific area to drive business or
customer-valued results.
2. Release Management Team:- Release Management team is responsible for planning,
scheduling, and controlling the build, in addition to testing and deploying Releases.
3. Governance Framework:- It basically improves coordination by ensuring all members
of your team are working together to achieve project deadline.
4. Change Control Board:- It is a committee that makes decisions regarding whether or
not proposed changes to a software project should be implemented. In other words, whether
or not any changes to the Baseline Requirements, agreed with the client, should be taken up
by the project team for approval from this committee.
5. Executive Sponsor:- The sponsor champions the project by acting as the project’s
highest level change leader – communicating the importance to stakeholders and senior
leadership; and, obtaining go-ahead decision and collaboration. The sponsor is accountable
for (owns) the solution’s success by – supporting the project manager; facilitating problem-
solving; ensuring that the solution is sustainable; and, exercising strategic control to achieve
project objectives and business benefits.
6. Architecture Review Board:- They will be responsible for defining the overall
structure of a program or a system. They will also be overseeing IT assignments that are
aimed at improving the business and ensuring that all parts of the project run smoothly.
7. Steering Committee:- steering committee is a group of high-level advisors who have
been asked to govern an organization or organizational segment and provide it with direction.
2. Familiarize yourself with different types of development environments and know which
to use when – Development, Integration testing, Regression testing, UAT, Staging,
Production Debugging. For example, At Gurukul on Cloud (GoC), they just completed the
development of a batch Apex. This will only work on Lead record – to delete a record that
doesn’t have an email address. In this scenario, which sandbox will you use to test the batch
job to make sure that it will work as per requirement – assuming that, at present, Full copy
sandbox (they have only one) is used to fix a major production bug.
3. Design Standards: – Make sure that you understand Salesforce design standard. For
example, Bulkification of code, Standard methods for deprecating classes and fields, and
development best practices.
4. Project development Methodologies: – Understand the difference between Waterfall and
Agile methodology. Make sure to understand how to select project methodology based on
requirement, deadline, and budget.
5. Thoroughly master different deployment tools and know which to use when. Understand,
in which scenario, it is better to use [Link] Migration Tools, [Link] IDE, Packages,
and Change Sets. For example, At GoC they are currently implementing a project to integrate
Salesforce with their in-house ERP system. Developer or TA doesn’t have access to the
production instance of Salesforce and IT team is responsible for deployment. Which of the
following tools fit in this requirement?
 * [Link] IDE
* [Link] Migration Tool
* Manage Package
* Unmanaged Package
6. Continuous Integration:- You do not need to use Continuous Integration tools. But, make
sure you understand its purpose and some considerations when advising its implementation as
a technical architect. Learn about different CI tools available in the market for Salesforce.
Also, understand how these tools help you to manage source code repository.
7. Release management:- Understand the inter-dependency between Salesforce release and
development release schedule. How would you plan a release if there is an upcoming
Salesforce release?
8. Testing:- Testing the [Link] application (Unit test (QAT), Integration testing,
Regression testing, UAT, Performance testing, Security testing, Load testing, Stress testing
etc.).

Metadata Limits
The following limits apply to the Salesforce Extensions for Visual Studio Code, the Ant
Migration Tool, and the Metadata API.
Retrieving and deploying metadata
You can deploy or retrieve up to 10,000 files at once. AppExchange packages use different
limits. In API version 43.0 and 44.0, AppExchange packages can contain up to 12,500 files.
In API version 45.0, AppExchange packages can contain up to 17,500 files. In API version
46.0, AppExchange packages can contain up to 22,000 files. In API version 47.0 and later,
AppExchange packages can contain up to 30,000 files. The maximum size of the deployed or
retrieved .zip file is 39 MB. If the files are uncompressed in an unzipped folder, the size limit
is 400 MB. Note the following:
* If using the Ant Migration Tool to deploy an unzipped folder, all files in the folder are
compressed first. The maximum size of uncompressed components in an unzipped folder is
400 MB or less depending on the compression ratio. If the files have a high compression
ratio, you can migrate a total of approximately 400 MB because the compressed size would
be under 39 MB. However, if the components can't be compressed much, like binary static
resources, you can migrate less than 400 MB.
* Metadata API base-64 encodes components after they’re compressed. The resulting .zip file
can't exceed 50 MB, which is the limit for SOAP messages. Base-64 encoding increases the
size of the payload, so your compressed payload can't exceed approximately 39 MB before
encoding.
* You can perform a retrieve() call for a big object only if its index is defined. If a big object
is created in Setup and doesn’t yet have an index defined, you can’t retrieve it.
Change sets
Inbound and outbound change sets can have up to 10,000 files of metadata.

Unlocked Packages
Unlocked packages provide a repeatable, scriptable, and trackable vehicle for introducing and
managing change in your orgs. When you use unlocked packages, packages become the
containers you use to organize your metadata. Packages also become the way you migrate
that metadata between environments. And adopting packaging will impact how you manage
and think about the very structure of your Salesforce org.
To adopt unlocked packages, your team must also adopt modular app development and all the
good things that come with it, including:
* Better ownership of functionality
* More efficient change management
* More efficient development processes (quicker test runs, more maintainable code, and so
on)
* Decreased cost to deliver new features

Unmanaged Packages
Unmanaged packages are typically used to distribute open-source projects or application
templates to provide developers with the basic building blocks for an application. Once the
components are installed from an unmanaged package, the components can be edited in the
organization they are installed in. The developer who created and uploaded the unmanaged
package has no control over the installed components, and can't change or upgrade them.
Unmanaged packages should not be used to migrate components from a sandbox to
production organization. Instead, use Change Sets.
As a best practice, install an unmanaged package only if the org used to upload the package
still exists. If that org is deleted, you may not be able to install the unmanaged package.

Managed Packages
Managed packages are typically used by Salesforce partners to distribute and sell applications
to customers. These packages must be created from a Developer Edition organization. Using
the AppExchange and the License Management Application (LMA), developers can sell and
manage user-based licenses to the app. Managed packages are also fully upgradeable. To
ensure seamless upgrades, certain destructive changes, like removing objects or fields, can
not be performed.
Managed packages also offer the following benefits:
* Intellectual property protection for Apex
* Built-in versioning support for API accessible components
* The ability to branch and patch a previous version
* The ability to seamlessly push patch updates to subscribers
* Unique naming of all components to ensure conflict-free installs

Regression Testing:
* The main object of Regression testing is to test whether code and config releases is
affecting existing user processes of the system
* It will be conducted once a enhancement or a fix is deployed to production.
* The user provides a list of changes which may impact their current process
Load Testing:
It verifies the software product’s ability to perform under anticipated user loads.
Stress Testing:
It checks the system on its robustness and error handling under extremely heavy load
conditions