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?
- Will your users know how to use the new field, or will training be needed?
- If the field is required, are there any integrations or import processes which require updating?
- Should the field appear on all page layouts, list views, or in any reports or dashboards?
- Should the field be on the Lead object as well, and if so, does the Lead conversion process require updating?
- Will this field be required for integrations with other systems? This action might require changes to middleware, field mappings, endpoints, and so on.
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!
What Is Application Lifecycle Management?
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.
- Step 1: Plan
- An app starts with planning. This step includes requirements gathering and analysis. The product manager creates design specifications and shares them with the development team for implementation.
- Step 2: Build
- Administrators and software engineers write the app per the design specifications. The development is done on the Salesforce platform using declarative tools—the tools available in the user interface—and programmatic tools, such as Apex, Visualforce, and Lightning Components.
- Step 3: Test
- The app is tested to verify that the changes behave as expected and don’t cause undesired side-effects. The quality assurance team first performs unit and functional testing. A small set of experienced people then provide feedback (user acceptance testing). Staging the changes enables final testing before deploying to production.
- Step 4: Deploy
- When testing is successfully completed and the quality benchmarks have been met, the app can be deployed to production. The release manager manages releases to production. Training employees and partners about the changes is a best practice.
Development Lifecycle Roles
- Release manager—Manages the release schedule and coordinates releases with the business. The release manager could be in charge of pulling changes from version control.
- Product manager—Provides the business requirements of apps and features, and works with the development team to implement those requirements. The product manager also performs user acceptance testing to ensure that requirements have been implemented.
- Software developer—Develops new functionality in sandbox, including both declarative point-and-click development and code.
- Quality engineer—Tests new functionality in sandbox.
- Administrator—Performs administrative tasks in the production org, and tracks all changes made in production.
- Trainer—Conducts training of company employees for new applications and features.
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:
- Center of Excellence
- A few stakeholders from different functional groups work together to ensure that changes support business goals and follow IT best practices and processes.
- Release Management
- You’ve already learned how to use tools like change sets and a sandbox to manage changes. If you use a backlog list to manage priorities, you can work on the most important changes first. And if you design and document a complete release management process as you learn more about your organization, everyone who works with Salesforce will be able to know how to do so safely.
- Design Standards
- Follow key standards for coding, testing, integration, large data volumes, and other areas that affect the services you share with other Salesforce customers.
Create a Release Management Process
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.
- Bug fixes and simple changes that do not require formal release management, including reports, dashboards, list views, email templates, and user administration.
- Changes with limited impact, such as a new workflow rule or trigger impacting a single business process. These releases typically require testing, but limited training and change management, and are delivered within a few weeks.
- Changes with significant impact, including configuration and code changes with one or more dependencies. Because these releases greatly affect the user experience and data quality, they require thorough testing, training, and careful change management. Major releases typically occur once a quarter (or like Salesforce, three times a year). Releasing on the same day of the week for minor and major releases is a best practice. This allows for company-wide planning and sets expectations with your business users. In addition, don’t schedule releases near holidays or other major events.
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:
- Standard naming conventions
- Consistently using the Description field
- Bulkified code
- Standard methods for deprecating classes and fields
- Consistent data architecture across all projects
- Handling large data volumes
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.
Single Development and Test Environment
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.
- New custom objects, tabs, and applications
- Integrations with other systems
- Apps involving Visualforce, workflow, or new validation rules
Multiple Development and Test Environments
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 Central Source Control Repository with Multiple Environments
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.