As businesses depend on Salesforce more and more, Salesforce teams are feeling the pressure for faster delivery of more features. While teams try to ramp up the speed and scale of their delivery, it’s easy to lose track of work and make mistakes without a proper system in place.
The Salesforce application lifecycle management (ALM) framework can help give you an overview of your process, from tracking new development work through to maintaining your live environments. Read on to learn how ALM can help you get visibility over your Salesforce development.
What’s application lifecycle management?
With Salesforce teams facing demands from both end users and the wider business, it’s easy to focus only on release management — getting work successfully out the door as quickly as possible. This prioritizes the development and release of new features to meet immediate needs, but makes it easy to neglect the long-term health of your live environments, as maintenance is less of a priority and shortcuts may be taken in order to reach release deadlines.
By contrast, ALM encourages a holistic approach to your Salesforce development. Salesforce features, your “applications”, are viewed almost as a living organism with a “lifecycle” of various stages, all of which must be considered. This means that pre-development stages of a Salesforce release, such as gathering business requirements, and post-release steps, such as maintenance, are valued as much as the release of new features. Salesforce teams can also make use of other similar concepts such as the software development lifecycle (SDLC), although this is a little narrower in focusing on development and releases.
What are the different stages of application lifecycle management?
While the environments and tools they use will vary, all Salesforce teams can follow the core phases of the ALM:
- Plan your release by drawing together design specifications, end-user requirements, and business goals. This will help you to understand what a release is really trying to achieve. These conversations should be a two-way street — Salesforce admins and developers should also have the opportunity to question external requests or suggest specification changes. At a technical level, Salesforce teams should use this time to plan how best to execute the task — whether it can be achieved declaratively or needs custom code — and how the feature will be maintained.
- Develop the feature in an environment other than your production org, likely a development org. This can be done with the planned combination of declarative tools, such as Flow builder, and programmatic ones, such as an IDE like Visual Studio Code. You should continuously refer back to your plan to make sure you’re meeting the requirements and specifications.
- Test new development work. This is the time to test whether the new feature works as expected, rather than how it interacts with your wider production org.
- Build your release by combining the various tested pieces of development work. There are several tools and processes that you can use to do this, but the overarching goal is the same — packaging a set of development work into a bundle that’s logical and valuable to deploy to production.
- Test the build in an environment that mimics your production org, likely a full or partial copy sandbox. This should have an accurate representation of both your production data and the external systems connected to production, which will help you to understand how this release will affect your live environments. This is the time to run quality assurance (QA), alongside performance, regression and user acceptance testing (UAT).
- Release the final package to your production org. At this point, you should internally announce the release and provide training for end users if the release is providing new functionality.
- Maintain your release, both in terms of technical performance and end user adoption. Regularly test live features and review their performance each time there’s a Salesforce platform upgrade. Provide end users with opportunities to report problems and suggest improvements.
The DevOps Evolution
The concept of ALM emerged in the 1970s, as a way to achieve a well-structured codebase — which enterprises recognized was essential if developers were to have a hope of understanding and maintaining it. By the 2010s, it seemed ALM had run into trouble. Operations teams, completely separate from development teams, had to spend hours unpicking and resolving issues in live environments, and often found that their feedback to developers fell on deaf ears.
DevOps, the bringing together of development and operations, emerged as the new standard to solve both the technical and cultural problems that were undermining ALM. Like ALM, DevOps proposes that the development of new features should be intertwined with the operations of live environments, encouraging a strong and continuous feedback loop that produces better development work, time savings, and satisfaction in your Salesforce team.
Some have suggested that ALM should evolve into application development lifecycle management (ADLM), with the emphasis on the same team members using the same tools for each stage. But in essence, that’s the same emphasis as DevOps. In the Salesforce community, DevOps has become the standard way of thinking about ALM.
With DevOps, the same team members should be involved in each stage of the application lifecycle, with shared tooling — encouraging collaboration across your Salesforce team and allowing you to scale your approach as you grow. This makes the DevOps approach suitable for Salesforce teams at any stage of their maturity, as new tools and processes can be picked up at any time.
Why not take our Salesforce DevOps Assessment to evaluate how successfully your team has adopted DevOps practices.
Application lifecycle management tools
Your ALM tooling is the foundation of successful development work — they set the parameters of what’s possible and determine how efficiently you can work.
Native deployment tools
It isn’t possible to cover all of ALM with only native Salesforce tools, but they do provide a few release management options.
- Change Sets to deploy metadata changes downstream as a set. There are several limitations with change sets, including lack of visibility, no support for destructive changes, and no rollbacks.
- Salesforce CLI, which allows you to retrieve and push changes between development environments instead of using declarative tools. This does let you deploy destructive changes, but still offers little visibility and may alienate no-code teammates.
- Packages contain all the metadata for a feature, which can be deployed and installed as a whole. Packaging encourages separation of concerns, and in principle should help with ALM as each package effectively represents an “application”. In practice, teams often struggle to package up existing functionality.
- DevOps Center is Salesforce’s newest tool, which allows teams to package all metadata changes into “work items” that travel through the pipeline from development to production. However, this is still incompatible with most Git providers and branching strategies, alongside key work-tracking systems like JIRA or Rally.
Tools for planning, automation, monitoring and backup
While Salesfore’s deployment tools are workable, they can only be used for the release stage of the ALM. So, if you’re wanting to truly take advantage of DevOps and bring together your development and operations teams across the whole lifecycle, you’ll need to find tools that can stretch across all stages to give you an “integrated ALM”.
For example, CI/CD can be used for the testing, building, deployment and release stages of your ALM. Continuous integration introduces automation in your release cycles, to help you deliver value to end users more quickly. This accelerates the application lifecycle, tightens the feedback loop, and allows you to accurately meet business and user requirements at rapid speeds. As Salesforce native tools don’t offer any automation, you’ll want to look for a third-party tool to introduce CI/CD across your ALM.
Further, backing up your Salesforce data and metadata is inherent in the DevOps approach to ALM. Backup supports the final maintenance stage, as you’ll be able to restore a previous version of your production org from a backup in the event of any disruption or downtime. It also accelerates your release stage, as your team can confidently deploy changes knowing that they can roll a release back if anything were to go wrong. As Salesforce’s native backup and restore tools are limited, you’ll also want to look to a third-party vendor for this.
Monitoring tools support your operations, by continually checking the components of your live environments and alerting you to changes as they happen. This allows you to spot any problems much faster than you would manually, helping you to quickly develop fixes to resolve them.
As these tools are helpful across the phases of your ALM, they give you a truly “integrated” lifecycle. Rather than tools being siloed at specific phases, holistic ALM tools encourage productivity and accuracy within and between the stages of your lifecycle.
All the tools for Salesforce DevOps
From the most granular deployments, through to post-release maintenance, Gearset’s DevOps platform provides all the tools you need for successful ALM. If you want to give deployments, CI/CD, backup and much more a try — all in one place — start your free 30-day trial of Gearset today.
