Use the same account next time to pick up where you left off.
|Production Salesforce account||Developer Edition or Admin Playground|
|Do I need to be a Salesforce customer?||Yes||No (It's free!)|
|Can I use it to create my Trailhead profile and store my badges?||Yes||Yes|
|Can I use it to complete Trailhead challenges?||No (except for multiple choices quizzes)||Yes|
|Can I keep my Trailhead badges if I leave my company?||No||Yes (use a personal email address)|
Salesforce has two different user interfaces: Lightning Experience and Salesforce Classic. It’s easy to switch between the two. You can learn about switching between interfaces, enabling Lightning Experience, and more in the Lightning Experience Basics module here on Trailhead.
This module is designed for Salesforce Classic.
If you’ve done some of the challenges in Trailhead already, you know it’s easy to build and customize apps. For example, the Contact standard object doesn't have a field for Contact Type. You could easily add that custom field in your production org and make the Contact Type field immediately available to all users. But should you?
Non-configuration changes, such as creating views, reports, and dashboards, can be made safely in production. But other changes, such as this hypothetical new Contact Type field, are potential pitfalls of confusion and productivity. Understanding the downstream impact of a change, whether it’s preparing for a new user experience or updating an existing integration, are vital steps to minimize disruption and increase feature adoption. But how do you know when to make a change in production versus using sandbox (a separate environment for development and testing)?
The answer depends on your change management strategy. Some companies need the flexibility to make emergency changes in an ad hoc fashion, rather than as part of a scheduled upgrade. Other companies find this disruptive to users, administrators, and developers and opt to roll out their changes with a formalized release process. And some companies do a mixture of both.
This Trailhead module is different from the Change Management module. Here’s how they're different: If your use cases are simple and you are comfortable with change sets, you might prefer the Change Management module. If you have more complex needs, are an enterprise customer, or need more robust functionality than change sets provide, you might prefer this module. When in doubt, get both badges and decide for yourself!
Application lifecycle management is the process of managing an app’s development, from design to final release, and establishing a framework for managing changes. The typical application lifecycle starts with the design of a new app or feature. The app is planned based on requirements analysis and specifications. Next, the app is implemented per the specifications and then tested. The new app is staged for final testing before it gets deployed to production. This cycle repeats for every new app or feature. It’s also used for app maintenance, such as when features are enhanced or bugs are fixed. A governance and change management framework directs the development process.
You’ve learned how to keep your organization lean and clean using the tools that Salesforce provides. However, governance, a method of management, is about more than tools. Governance improves agility by ensuring all members of your team are working together to achieve goals that are aligned with overall business goals.
Three elements of a responsive, adaptable framework for governance are:
By using sandbox and permission sets, you’ve already created a simple release management process. Add structure by setting up a release schedule and defining criteria for major versus minor releases.
Salesforce is configurable, extendable, and supports integration with other applications and services. By following the same design standards, anyone who modifies your organization can ensure that their changes aren’t in conflict with another group’s changes. In addition, with Salesforce’s multi-tenant architecture, employing design standards helps ensure your changes stay within set governor limits.
Some examples of design standards include:
The architect or architecture team in your center of excellence defines your company’s design standards. Publish your design standards, and communicate them to all teams that work on Salesforce projects, and the rest of IT.
Let’s take a look at how to implement a software development cycle in Salesforce, starting with an easy example using a single development and testing environment. Each development and testing environment is represented in Salesforce by a sandbox. You learn more about sandboxes in a later unit.
For small or quick projects, it’s possible to simplify the development lifecycle by using a single environment for development and testing. If you’re just getting started developing in a sandbox, using a single environment is a good way to begin.
As your development process matures, you’ll find that having multiple sandboxes allows greater flexibility. Even adding a single sandbox for testing frees up the developer sandbox for new features while testing proceeds.
This scenario starts to show its limitations when you have more than one developer working in the sandbox. In short, you can count on conflicts and overwriting changes. In this case, it can be better to have each developer work in their own Developer Edition org and deploy to the sandbox as a means of integration.
When you have multiple developers in multiple sandboxes, you need to merge changes between the sandboxes before you deploy, which requires an integration sandbox. As you add more sandboxes to separate development projects, testing, and deployment, the picture becomes more complete. This next diagram shows the environments used for a development project slightly more complex than the previous one. The team has two developers, each with a sandbox. The changes from the developers are merged into a single testing environment (QA). After testing is completed, the changes are pushed to an environment where staff other than engineers can perform user acceptance testing (UAT). For example, product managers can use the UAT environment to ensure that the features work as expected and demo them. Finally, to ensure a smooth release to production, the changes are first staged in the staging environment and then released.
Alternatively, changes from multiple developers can be merged in an external source control system. The source control system hosts the metadata (which includes source code) of projects in development in separate branches. When the app is deployed to production, it’s deployed from the source control system. The following diagram shows a comprehensive release cycle with all the intermediate development, testing, and staging environments. This release cycle uses a source control system.
Use a source control repository, such as git, for team development. Using an external source control repository enables merging changes from multiple developers. Also, the repository allows isolation of projects that are in development. The source control repository is the source for all customizations deployed to all other environments. After the changes have been tested and validated in the various environments, a test deployment is made to the staging environment. If the deployment succeeds, the changes are migrated to production. This next diagram shows the various environments used in a team development project. The diagram is broken up in the different phases of the development lifecycle for releasing an app.
Here are some tips: