Software Development Lifecycle
Software Development Lifecycle (SDLC) is a software development practice that focuses on the planning, creation, testing, and deployment of software applications, from its initional inception through to end-of-life. This includes the development and release of the software, as well as the maintenance and support of the software after it has been released. This document is based upon Salesforce's own Well Architected Framework, and is intended to be used in conjunction with it; this page is a summary with a focus on developing within a Seven20 environment.
Without such a practice, development can quickly become chaotic and unmanageable, leading to poor quality software, missed deadlines, and unhappy customers. Symptoms of such chaos include:
- Slow and error-prone development cycles
- Intensive and difficult deployments
- High-severity issues or bugs discovered in production and post-QA environments
- Reliance on rollbacks or hot-fix deployments to stabilize releases
Because the SDLC encompasses the entire process of software development, it is important to have a well-defined and well-documented process that is followed by all developers and stakeholders. There are three key areas to building a good SDLC within a Salesforce-based project:
- Release Management Strategy
- Environment Strategy
- Testing Strategy
Release Management Strategy
Release management involves the planning and execution of migrating changes throughout different environments, e.g. from Development to Production environments. Any release into an existing system introduces a level of risk, where a previously stable system shifts into a new state, which may no longer be stable, with new bugs and issues introduced. Ensuring the process of releasing changes is well defined, repeatable and atomic is key to ensuring the stability of the system.
In its simplest form, a good release management strategy consists of the following:
- Source control-based development and releases. Never use an org-based development model
- Use a consistent release mechanism. e.g. deployments via SFDX
- Give releases a unique identifier. e.g. release version number or name
- Keep track of dependencies
Overall, the use of Unlocked Packages is the recommended approach for managing releases in Salesforce, although this is not always possible. In such cases, the use of a source control-backed SFDX project, using the Salesforce CLI, is the next best approach.
Failure to use any source control on a project rapidly leads to chaos and instability. This not only has financial impacts, such as extra time being spent to manage releases, but also leads to poor team morale and a higher staff turnover. A basic workflow can be easy to learn and adopt; a complex source control strategy is not required to reap the benefits of using source control.
Environment Strategy
Salesforce provides a variety of different environments which can be used throughout a project's lifecycle. Understanding how best to use the different environments and how best to manage them is key to ensuring a stable and efficient development process. A key part of this is ensuring environments accurately reflect the production environment, along with them being isolated from production.
Properly managing an environment strategy enables the following:
- Faster development times
- More reliable testing
- Easier debugging
- More stable releases
- Better understanding of the system
- Rapid environment setup/teardown
- Closer alignment to production
Using a source control-backed SFDX project is the best way to manage environments in Salesforce, as it removes a lot of the challenges previously presented from an org-based development model. Alongside this, choosing the correct environments for the correct tasks is key to ensuring a stable development process.
| Environment | Use Cases | Notes |
|---|---|---|
| Scratch Orgs | Prototyping, Feature development, Proof-of-concepts | Preferred for development if the org is fully source-backed |
| Developer/Developer Pro Sandbox | Prototyping, Feature development, Proof-of-concepts, User acceptance testing | |
| Partial Copy Sandbox | User acceptance testing, User training | |
| Full Copy Sandbox | User acceptance testing, User training, Performance and scale testing | Unless absolutely necessary, use a different Sandbox type |
A common strategy is to force changes to be released via specific environments, i.e. all work goes via UAT. In a source-based development model, this is not necessary, as the source is the source of truth. The greater flexibility provided by source control allows for a more agile development process in how, where, and when, changes are tested.
Always separate development and testing environments. The development of a piece of functionality should be done entirely independently from the testing of that functionality. Always deploy changes to an independent environment for testing.
Development and testing environments should be ephemeral and disposable. They should be created and destroyed as needed, with no long term data/metadata stored in them.
Testing Strategy
Testing is a key part of the SDLC, ensuring that the software being developed is of a high quality and meets the requirements of the stakeholders. There are many different types of testing that can be done, each with their own benefits and drawbacks. The key to a good testing strategy is to have a mix of different types of testing, each with their own focus, and a clear understanding of how, when and why each different type of testing is done.
- Test iteratively, frequently and automatically
- e.g. Automatically run Apex tests when merging a new piece of functionality
- Recognise changes which do not need testing
- e.g. Changes to page layouts may not require testing, where as changes to a Screen Flow would
- Define which environments to perform different types of testing in
- e.g. Regression testing is more accurate when done in a UAT environment
- Perform stress and performance testing
- e.g. If a piece of functionality is expected to be run against large data sets, test it against large data sets
- Never use production data
- e.g. Always use anonymised data for testing, never take the risk of using production data
- Test non-functional requirements
- e.g. Create and maintain test data sets for dataloading behaviour